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EXECUTIVE  SUMMARY 


This  report  compiles  Lessons  Learned  from  several  unmanned  ground  vehicle  (UGV) 
programs  that  could  be  relevant  to  the  objectives  of  the  Very  Shallow  Water  (VSW)  Mine 
Countermeasures  (MCM)  and  Explosive  Ordnance  Disposal  (EOD)  Unmanned  Underwater 
Vehicles  (UUV)  program. 

Lessons  Learned  were  collected  from  over  50  experts  within  the  UGV  community, 
through  interviews  and  reviews  of  published  work.  Lessons  Learned  were  also  inferred  from 
an  analysis  of  the  evolution  of  certain  UGV  efforts.  The  Lessons  Learned  are  organized  and 
presented  in  this  report  within  three  general  areas:  operations,  programmatics,  and 
technologies. 

The  recurring  operational  Lessons  Learned  involve  issues  of  control  unmanned  vehicles 
operating  among  and  in  collaboration  with  humans.  Aside  from  the  technological  deficiencies 
of  onboard  information  processing,  and  of  the  persistent  use  of  open-loop  sensing  in 
teleoperated  and  supervisory  controlled  vehicles,  the  difficulties  in  control  result  primarily 
from  communication  problems.  Most  control  strategies  now  depend  upon  communications, 
and  communications  are  undependable,  because  there  are  many  vulnerabilities  in  its  chain, 
including  the  likelihood  of  jamming  in  tactical  situations.  The  problems  of  communications 
and  control,  common  to  the  UGV  environment,  are  exacerbated  for  VSW  mine 
countermeasure  tasks  by  the  opacity  to  radio  frequency  (RF)  energy,  multipath  for  sound,  and 
other  sources  of  noise  in  that  environment.  Control  remains  a  significant  operational  problem 
on  land  and  in  the  water. 

The  recurring  programmatic  Lessons  Learned  involved  the  management  of  customer 
expectations  and  the  definition  of  useful  products,  both  of  which  generally  exceed  the 
prevailing  technological  possibilities  and,  as  a  consequence,  limit  opportunities  for  funding. 
Involving  the  user/customer  early  in  the  development  cycle,  often  through  operational  testing 
of  prototypes,  successfully  shaped  expectations  and  defined  and  developed  a  few  feasible 
applications.  Because  robotics  applications  are  new  to  the  operational  environment,  it  is 
important  to  provide  useful  products  in  the  beginning  that  will  engender  user  acceptance  of 
the  technology  and  facilitate  the  necessary  research  and  development  (R&D)  to  provide  the 
required  capabilities. 

The  recurring  technology  Lessons  Learned  clustered  around  the  problems  of  making  sense 
out  of  the  available  onboard  sensor  data  to  automatically  generate  appropriate  UGV  control 
commands.  Human  perception,  which  permits  successful  teleoperation,  is  beyond  the 
capabilities  of  contemporary  machine  perception  algorithms.  The  workaround  solutions 
generally  have  involved  non-human  mechanisms  (i.e.,  short-range  sound  navigation  and 
ranging  (SONAR)  for  automatic  object  detection  in-doors,  mid-range  laser  detection  and 
ranging  (LADAR)  for  automatic  object  detection,  the  global  positioning  system  (GPS)  for 
automatic  localization  out-of-doors,  tags  for  cooperative  target  recognition,  and  the 
restrictions  of  movement  to  navigable  pathways  in  both  environments).  Few  of  these  methods 
are  likely  to  work  underwater.  However,  for  VSW/surf-zone  (SZ)  operation,  in  addition  to 
SONAR,  chemical  and  tactile  detectors  may  be  used  for  mine  detection,  localization,  and 
classification,  if  further  research  and  development  investments  are  made. 
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Following  our  presentation  of  the  Lessons  Learned  from  those  UGV  experts  that  we  had 
an  opportunity  to  interview,  we  took  editorial  liberty  and  presented  near  the  end  of  this 
reportlO  issues  that  we  feel  deserve  greater  attention  in  the  robotics  community.  These  issues 
probably  will  not  attract  universal  agreement.  They  represent  an  alternative  view  of  the 
situation.  As  a  counterpoint,  our  10  issues  may  stimulate  dialogue  essential  to  the  discovery 
of  new  solutions  to  the  persistent  problems  that  the  reader  will  find  evident  herein. 

The  top  10  issues  are  as  follows: 

Uncertainty  promotes  survival.  Whether  robots  are  used  in  logistical  support,  in 
reconnaissance,  surveillance,  and  target  acquisition  (RSTA)  support,  or  in  tactical  force 
projection,  they  must  be  survivable.  An  adversary  that  is  uncertain  of  the  robot's  next  move  is 
less  likely  to  prepare  an  appropriate  countermove.  Operators,  however,  prefer  to  accurately 
predict  and  control  the  behavior  of  their  robots.  While  this  provides  advantages  for  safe — if 
limited — operation  among  friendly  forces,  predictability  has  definite  disadvantages  for 
operation  among  hostile  forces.  Therefore,  a  degree  of  uncertainty  must  be  inherent  in  robot 
controllers  for  those  robots  to  be  successfully  used  in  tactical  operations. 

Uncertainty  also  promotes  perception.  An  indeterministic  controller  (based  on  fuzzy  logic 
and  bi-directional  mapping)  is  uncertain  to  itself  as  well  as  to  observers,  permitting  the 
construction  of  internal  hypotheses  or  expectations.  These  hypotheses  drive  behavior.  Self¬ 
certainty  is  improved,  without  sacrifice  to  survivability,  through  the  processes  of  feature 
prediction  precedent  to — and  validation  consequent  to — self-generated  behavior.  Therefore,  a 
degree  of  uncertainty  must  be  inherent  in  robot  controllers  for  those  robots  to  be  successfully 
employed  in  uncertain  environments. 

Many  simple  cooperating  agents  are  superior  to  one  complex  agent.  The  superiority  of 
large  numbers  has  always  been  valid  in  military  affairs.  It  is  based  on  inviolable  physical 
principles.  It  applies  to  natural  organisms,  and  will  apply  to  robotics  as  well.  The  downside  in 
using  large  numbers  of  robots  in  the  military  context  is  in  the  difficulty  of  control.  Operators 
will  be  wary  of  such  agents  when  control  is  a  question.  New  operational  doctrine  will  likely 
be  required  to  accommodate  many  robot  agents  in  a  tactical  environment.  New  methods  for 
multi-agent  coordination  will  be  required  to  effectively  apply  many  simple  robots  to  any  task 
currently  performed  by  humans.  For  this  reason,  there  is  a  high  program  risk  to  the  early 
dependence  upon  multi-agent  coordination  for  prosecution  of  the  VSW  MCM  task. 

New  technology  forces  changes  in  operations.  The  military  community  tends  to  view 
technology  as  an  enabler  of  operations,  but  history  has  demonstrated  repeatedly  that  new 
technology  is  a  transformer  of  military  operations.  As  new  technology  forces  changes  in 
operations,  it  is  preferred  to  force  those  changes  upon  our  adversaries,  and  for  developers  and 
users  first  adapt  to  them.  Thus,  developers  and  users  must  remain  alert  to  the  opportunities 
for  operational  change  that  would  be  permitted  and  required  by  introducing  different  robotic 
technologies. 

Understanding  between  the  user  and  the  developer  is  critical.  Successful  programmatic 
decisions  cannot  be  made  without  the  program  office/developer  and  the  user  acquiring  a 
comprehensive  understanding  of  each  other's  constraints,  capabilities,  and  expectations.  The 
user  has  come  to  the  program  office  with  a  problem  because  old  methods  of  operation, 
supported  by  old  technology  solutions,  no  longer  work.  To  accomplish  a  new  solution,  the 
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developer  must  understand  the  application  and  offer  new  technologies  that  improve 
operational  efficacy,  while  the  user  must  understand  the  proposed  solution,  and  adjust  his 
methods  of  operation  accordingly.  The  optimal  solution  is  a  result  of  the  combined 
contributions  from  the  developer  and  the  user. 

Understanding  the  technology  is  cost-effective.  Because  the  natures  of  the  end-state 
solutions  to  the  VSW/SZ  MCM  problem  are  not  known  with  certainty,  successful 
programmatic  decisions  cannot  be  made  without  a  comprehensive  understanding  of  the 
evolutionary  possibilities  of  the  supporting  technologies.  The  program  office  must  maintain  a 
continuous  survey  of  the  emerging  technological  capabilities  in  all  areas  of  relevance  to  the 
problem.  This  knowledge  should  enable  the  program  office  to  pursue  the  most  promising 
long-term  investments. 

Simpler  solutions  provide  better  foundations.  Our  definition  of  a  simple  solution  is  that 
process  that  meets  a  few  of  the  requirements  without  violating  any  of  the  other  requirements 
applicable  to  the  system  in  which  it  resides.  By  contrast,  a  complicated  solution  is  that 
process  that  meets  some  of  the  requirements  while  integrating  badly  with  more  traditional 
solutions  to  the  remaining  requirements.  Requirements  may  be  added  to  the  solution  only  as 
long  as  the  principle  of  simplicity  is  maintained.  Natural  selection  in  evolution  is  the  model 
for  this  process. 

Integration  is  not  easy.  When  humans  pick  up  a  tool,  whether  the  tool  is  a  new  transducer 
of  environmental  emissions  like  an  infrared  (IR)  camera,  or  is  an  old  force  multiplier  like  a 
lever,  the  tool  is  used  through  the  existing  innate  capabilities  to  process  data  to  and  from  our 
five  senses  and  many  muscle  groups.  When  we  attempt  to  provide  similar  tools  to  a  robot, 
that  is,  when  we  attempt  to  integrate  some  function,  we  face  two  difficulties:  (1)  the  robot  has 
little  if  any  innate  capability,  and  (2)  the  robot  has  little  or  no  capacity  to  adapt  to  the  new 
tool.  Thus,  the  robot  is  to  some  extent  redesigned  with  each  addition  of  a  tool.  This  redesign 
is  the  fundamental  problem  of  integration.  The  difficulties  of  integration  would  be  minimized 
if  the  robot  employed  an  existing  interface  to  use  new  tools,  and  if  the  robot  could  cooperate 
through  adaptations  of  its  control  algorithms.  These  adaptations  are  a  proven  method  of 
vertical  (hierarchical)  integration.  Robotics  developers  should  first  identify  and  implement 
task-independent,  adaptive,  and  general-utility  core  capabilities  in  the  robot.  The  core 
capabilities  should  then  facilitate  the  incorporation  of  unique  tools  designed  to  address  the 
special  circumstances  of  the  assigned  tasks  and  environments.  There  is  a  significant  program 
cost  risk  in  pursuing  solutions  that  do  not  integrate  vertically. 

Communications  are  not  dependable.  Even  under  the  best  of  circumstances,  wisdom 
dictates  a  judicious  independence  from  communications.  Humans  get  by  with  very  low 
capacity  and  low  reliability  communications  for  this  reason.  The  most  useful  robots  will 
demand  the  least  from  humans  during  task  performance.  Autonomy  will  be  necessary  to 
permit  the  low  levels  of  communications  that  will  be  available.  Robotics  developers  should 
explore  technology  and  operational  solutions  that  capitalize  upon  local  autonomy  and  reduce 
communication  requirements.  There  is  a  significant  operational  risk  in  a  dependence  upon 
communications,  including  satellite  communications  that  serve  the  GPS. 

Automaticity  is  not  autonomy.  Implementing  automatic  processes  on  a  robot  can  reduce 
the  decision-making  requirements  of  the  human  operator,  but  risk  functional  failure  when  the 
control  algorithms  that  govern  the  automatic  processes  have  not  been  designed  for  the 
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prevailing  conditions  that  either  generate  or  require  a  response.  It  should  be  very  difficult,  if 
not  impossible,  for  programmers  to  provide  for  every  exception  in  critical  stimulus 
conditions  for  which  a  novel  response  will  be  required.  Autonomy  results  from  the  self- 
modulation  of  responses  (reflexes)  that  impact  conditions  in  the  internal  and  external 
environments,  based  upon  the  confluence  of  factors  prevailing  in  both,  following  rules  that 
promote  the  integrity  and  well-being  of  the  agent.  The  criterion  for  successful  autonomy  is 
survival,  for  which  all  novel  responses  are  ultimately  organized  and  executed.  If  survival  is 
not  a  required  mission  or  task  objective  of  the  robot,  then  its  processes,  while  automatic,  will 
not  be  autonomous,  and  the  robot  will  likely  fail  as  soon  as  the  operating  conditions  deviate 
from  the  designed  range  of  its  automatic  mechanisms.  Developers  should  first  provide 
application-independent  autonomous  capabilities  for  their  robots.  These  capabilities  will 
establish  the  necessary  basis  for  the  evolution  of  systems  capable  of  dealing  adaptively  and 
appropriately  with  complex  and  unpredictable  environments. 

The  road  from  teleoperation  to  autonomy  does  not  exist.  The  road  from  teleoperation  to 
automaticity  probably  does  exist,  but  automaticity  is  not  autonomy.  The  mechanisms  of 
autonomy  are  fundamental  and  are  re-expressed  at  all  higher  levels  of  the  control  architecture 
of  an  autonomous  system.  They  are  bypassed  only  in  pathology  and  disease.  If  robot 
autonomy  is  our  objective,  and  if  humans  remain  in  the  robot  control  loop,  then  inadequacies 
in  our  robot  control  algorithms  will  be  masked,  and  we  will  continue  to  build  upon  a  false 
foundation  to  achieve  autonomous  capabilities.  We  should  not  attempt  to  follow  a  roadmap 
from  teleoperation  through  semiautonomous  to  autonomous  capabilities,  for  that  road  does 
not  exist  in  reality.  Rather,  we  should  develop  capabilities  of  fully  autonomous,  though 
behaviorally  simple,  robots  from  the  onset,  following  the  principles  of  autonomy  outlined 
herein.  But  to  do  this,  we  must  start  with  the  simplest  of  tasks  and  add  task  and  behavioral 
complexity  only  to  the  degree  that  autonomy  is  not  compromised. 
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1.  INTRODUCTION 


1.1  PURPOSE 

The  purpose  of  this  effort  is  to  compile  Lessons  Learned  from  the  unmanned  ground 
vehicle  (UGV)  programs  that  could  be  relevant  to  the  objectives  of  the  Very  Shallow  Water 
(VSW)  Mine  Countermeasures  (MCM)  and  Explosive  Ordnance  Disposal  (EOD)  Unmanned 
Underwater  Vehicle  (UUV)  program. 

Even  though  the  operational  environments  of  the  UGV  programs  and  the  UUV  program 
are  significantly  different.  Lessons  Learned  could  save  the  VSW  MCM  UUV  program 
considerable  time  and  resources. 

The  domain  of  relevant  Lessons  Learned  could  include  program  management  and 
contracting,  operational  concepts,  sensor  processing  and  navigation  control  software,  multi¬ 
vehicle  coordination  processes,  and  other  related  robotics  technologies. 

All  of  the  above  issues  each  fall  into  one  of  three  general  subject  areas: 

1.  Operations 

2.  Programmatics 

3.  Technologies 

Operations  deals  with  the  use  of  the  agents  in  the  assigned  tasks  and  mission 
environments.  Generally,  operations  will  involve  the  cooperation  of  robotic  agents  and 
human  operators  who  currently  performed  the  tasks,  and  who  will  either  collaborate  in  the 
tasks,  or  will  perform  other  tasks  in  the  same  mission  environment. 

Programmatics  deals  with  the  process  of  defining,  funding,  designing,  producing,  testing, 
defending,  supporting,  disposing,  and  certifying  the  robotic  agents  for  the  intended  tasks  and 
missions. 

Technologies  are  the  broad  range  of  capabilities  that  support  the  robotic  agent  in  the 
performance  of  its  tasks  and  missions,  including  power,  communications,  sensors,  actuators 
and  effectors,  control  algorithms,  and  computational  hardware. 

We  present  herein  Lessons  Learned  as  reported  by  prominent  members  of  the  UGV 
development  community  in  each  of  three  general  subject  areas  defined  above,  interspersed 
with  our  own  editorial  opinions  on  the  issues. 

1.2  APPROACH 

1 .2.1  What  are  Lessons  Learned? 

We  presume  that  Lessons  Learned  are  the  conscious  and  communicable  awareness  of  the 
consequences  of  different  actions,  where  some  consequences  are  approved  while  others  are 
regretted. 
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1 .2.2  Where  can  we  find  Lessons  LearnecH 


Lessons  Learned  are  often  acquired  by  trial-and-error  experience,  and  then  written  down 
by  the  considerate  developers  and  users  of  robotic  systems  and  published  for  the  benefit  of 
others.  We,  therefore,  sought  out  and  studied  these  informative  publications. 

More  often,  however,  Lessons  Learned  are  the  essence  of  experience,  and  are  indirectly 
acquired  by  the  inexperienced  only  by  enrolling  in  formal  courses  of  instruction.  To  gain  the 
benefits  of  others’  experience  outside  the  classroom,  we  must  persuade  each  teacher  to 
provide  a  private  tutorial.  This  we  have  attempted  to  do  through  personal  interviews. 

Most  often,  however,  Lessons  Learned  remain  as  unconscious  or  undocumented  solutions 
to  problems  that  no  longer  recur  in  the  particular  developmental  effort.  They  warrant  no 
further  attention,  and  disappear  from  consciousness.  The  only  way  to  recover  these  Lessons 
Learned  is  to  examine  the  evolution  of  the  product  and  reconstruct  the  problems  and  their 
solutions  from  the  design  or  procedures  that  are  presently  working. 

For  example,  in  earlier  times,  when  man  fought  with  horse,  lance,  arrow,  and  sword,  the 
fortified  castle  proved  to  be  an  effective  method  of  defense  for  a  disadvantaged  population. 
By  observing  the  operational  use  of  castles  under  threat  conditions,  we  could  infer  that  the 
defenders  had  learned  that  high  thick  walls  improved  their  chances  for  survival.  With  the 
introduction  of  gunpowder,  this  lesson  was  no  longer  valid.  Castles  crumbled  and  new 
lessons  had  to  be  learned.  One  such  lesson  was  that  the  faster  one  moved,  the  less  likely  one 
would  become  a  target.  Mobility  and  maneuverability  then  resumed  dominance  in  military 
tactics. 

The  behavior  of  the  practitioners,  as  much  as  their  tutelage,  can  inform  us  of  the  lessons 
that  they  have  learned.  We  have  therefore  added  commentary  to  our  compiled  listing  of 
admitted  Lessons  Learned  that  analyzes  aspects  of  the  behavior  of  the  robotics  developers 
and  users.  This  commentary  represents  our  assessment  of  the  factors  that  have  driven  and 
may  continue  to  drive  the  development  and  application  of  UGVs. 

1.2.3  Sample  Domain 

We  identified  robotics  experts  in  government,  academia,  and  industry  primarily  by 
reputation.  We  sent  e-mail  to  these  individuals  for  their  Lessons  Learned,  and  followed  those 
requests  in  most  cases  with  telephone  calls  to  complete  their  interviews.  Other  experts  were 
referred  to  us  by  our  original  list  of  contacts,  and  our  information  gathering  process  was 
repeated  with  those  referrals.  We  regret  the  omission  of  other  prominent  robotics  experts  with 
whom  we  failed  to  make  contact. 

1.2.4  The  Returns 

In  the  time  allotted  for  data  collection  we  received  hundreds  of  Lessons  Learned, 
contributed  by  over  50  experts  in  robotics  technology  development  and  robotics  program 
management,  that  are  potentially  relevant  to  the  development  and  employment  of  small 
unmanned  underwater  vehicle  systems  in  the  VSW  MCM  mission.  The  scope  of  the  Lessons 
Learned  is  apparent  from  the  fourth  level  of  the  table  of  Contents  of  this  document,  while 
Section  6  lists  all  cited  contributors. 
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Table  1  lists  the  Government  Program  Offices,  Government  Laboratories,  Academic 
Institutions,  and  Commercial  Enterprises  from  which  we  received  those  Lessons  Learned. 


Table  1 .  Organizations  contributing  Lessons  Learned. 


Program  Offices 

Other 

Gov. 

Gov.  Labs 

Academic  Labs 

Commercial 

UGV/SJPO  (RCSS, 

SRS,  Gladiator,  MPRS,  TUV, 
Viking ) 

IDA 

NIST  (XUV) 

WHOI  (REMUS) 

SAIC  (XUV) 

TARDEC  (XUV) 

NAVSEA 

Sandia  (Hagar, 
Hopper ) 

use  (SCOWR, 

MARS,  Urbie) 

Titan  (SRS) 

PMS  EOD  ( BUGS , 

RONS ) 

DTRA 

SSC  SD 

(MDARS-I,  MDARS- 
E,  MPRS,  AUSS) 

CMU  (Gyrover, 

Urbie) 

GDRS  (MDARS- 
E,  XUV) 

AFRL  (ROCS,  ARTS ) 

OSD 

JPL  (MARS, 

FIDO,  Urbie, 
Nanorover ) 

Georgia  Tech. 

PSE  (MDARS-I,  MDARS- 
E) 

TRADOC 

MIT  (DARTs) 

iRobot  (ALUV, 
DARTs,  Fetch  II, 

Urbie) 

ARL  (UGVTEE,  XUV, 

FCS ) 

DARPA  (MARS,  TMR- 
Urbie) 

NSF  (SCOWR) 

ONR  ( Gladiator ) 

Robotics  products  are  indicated  in  \i& 

ics.  Organizations  with  robotics  experts  contributing 

Lessons  Leaned  are  indicated  in  boldface  type 

1.3  ORGANIZATION  OF  THIS  DOCUMENT 

This  report  is  organized  as  follows.  Section  2  discusses  some  of  the  operational  factors 
that  contribute  to  the  present  VSW  MCM  mission.  Section  3  lists  open  issues  and  outstanding 
difficulties  in  VSW  UUV  technology  and  operations.  Section  4  catalogues  and  elaborates  on 
specific  Lessons  Learned  from  the  UGV  community.  Section  5  summarizes  10  significant 
issues  arising  from  the  Lessons  Learned  and  offers  recommendations  to  the  VSW  MCM 
UUV  Program  Office.  References  and  sources  cited  are  listed  at  the  end  of  this  report. 
Appendices  provide  additional  information  for  reference. 

The  presentations  of  UUV  open  issues  and  UGV  Lessons  Learned  in  Sections  3  and  4 
respectively  are  organized  along  the  three  subject-area  categories  listed  above,  and  at  a 
second  level,  along  specific  issues  of  program  office  concern.  This  organization  is  for 
convenience  of  presentation  only,  and  does  not  imply  any  independence  of  operational, 
programmatic,  and  technological  issues.  Where  obvious  dependencies  exist,  we  will  try  to 
note  them. 

In  the  following  three  sections,  information  that  comes  primarily  from  either 
transcriptions  of  interviews  with  experts  or  from  extractions  of  published  material,  are 
indicated  by  references  and  by  1 /2-inch  indentations  of  text.  Each  reference  includes  the 
originator's  last  name  and  source  date  in  boldface  font  [...].  The  originator's  full  name, 
source,  and  contact  information  are  available  in  Section  6.  The  editors  freely  introduce  and 
provide  commentary  upon  the  referenced  Lessons  Learned  with  material  that  is  neither 
referenced  nor  indented.  This  material  should  be  considered  as  editorial  opinion. 
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2.  The  VSW  MCM  Mission  and  Environment 


2.1  SOURCES  OF  INFORMATION  ON  THE  VSW  MCM  MISSION  AND  ENVIRONMENT 

The  Office  of  Naval  Research  (ONR)  released  a  Broad  Agency  Announcement  (BAA)  in 
February  1998  to  solicit  studies  of  systems  and  technologies  that  would  support  manned  and 
unmanned  VSW  MCM  missions.  With  this  BAA,  ONR  provided  online  an  information  paper 
that  summarized  the  VSW  MCM  mission  and  its  environment  [ONR,  1998], 

A  recent  published  source  for  information  on  the  VSW  MCM  environment  is 
Oceanography  and  Mine  Warfare.  This  publication  is  also  available  online  [NAS,  2000]. 

An  operator's  perspective  on  the  VSW  MCM  mission  is  available  in  the  Proceedings  of 
the  4th  International  Symposium  on  Technology  and  the  Mine  Problem  [James,  2000]. 

2.2  KEY  CONSIDERATIONS  ON  ENVIRONMENT,  PROCEDURES,  AND  TECHNOLOGY 

The  following  paragraphs,  outlining  the  current  environment,  procedures,  limitations,  and 
technology,  were  provided  by  ABHC  Scott  Trieble,  the  sole  member  of  the  UUV  platoon  of 
the  only  existing  VSW  MCM  detachment  in  the  U.S.  Navy. 

2.2.1  Operational  Environment 

Very  shallow  water  (VSW)  is  defined  as  that  expanse  of  water  proximate  to  the 
shore-line  with  a  depth  of  from  40-10  feet.  The  surf  zone  (SZ)  is  defined  as  the 
remaining  water  from  10  feet  of  depth  to  the  beach.  The  VSW/SZ  contains  a  variety 
of  obstacles  including  rocks,  kelp,  and  eelgrass.  Visibility  is  typically  from  0-5  feet  in 
the  daytime.  Buoyant  objects  are  subject  to  significant  back-and-forth  surge  currents. 
The  slope  of  the  shelf  to  the  beach  is  uncertain  and  locally  variable.  Depending  upon 
the  slope,  the  range  between  the  possible  locations  of  hostile  forces  on  the  beach  and 
the  locations  of  MCM  activity  in  the  VSW/SZ  can  be  from  a  few  yards  to  a  few 
thousand  yards.  [Trieble,  2001] 

2.2.2  Current  Procedures 

VSW  MCM  operations  are  accomplished  at  present  using  a  combination  of  marine 
mammals  and  human  divers.  Dolphins  locate  potential  mines  using  endogenous 
sonar,  then  drop  pingers  to  tag  locations.  Human  divers  must  reacquire  the  locations 
by  orienting  to  the  pingers.  The  human  divers  then  attempt  to  visually  identify  the 
objects.  If  the  objects  are  mines,  the  divers  place  timed  charges  and  move  on  to  the 
next  pinger.  The  Navy  typically  does  not  employ  marine  mammals  and  divers  in  the 
SZ.  Brute  force  neutralization  by  the  laying  out  of  a  blanket  of  charges  is  used  there 
for  in-stride  breaching,  although  the  breaching  of  obstacles  in  the  surf  zone  is  still 
problematic.  [Trieble,  2001] 

The  mine-hunting/clearing  operations  are  carried  out  during  nighttime  because  the 
dolphins  must  be  brought  in  by  small  boat,  which  would  be  at  greater  exposure  to 
hostile  fire  during  the  daytime.  Human  divers  carry  small  chemical  lights  to  use  in 
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mine  identification.  If  marine  mammals  are  not  available,  the  human  divers  can  locate 
mines  using  the  AN-PQS2alpha  hand-held  sonar  unit.  Human  divers  have  a  lot  of 
gear  to  carry,  including  mine  neutralization  charges  and  the  pinger  localization  or 
sonar  equipment.  Deployment  of  divers  by  submarine  is  generally  not  feasible 
because  the  deeper  waters  in  the  approaches  to  a  possible  mined  landing  sight  are  also 
mined,  and  must  be  cleared  by  other  means  prior  to  submarine  transit. 

The  size  of  the  present  VSW  MCM  Detachment  is  approximately  seventy  personnel. 
Forty  are  in  operations  (mostly  diver  qualified),  eighteen  go  into  the  water,  twenty- 
one  service  and  control  the  dolphins,  and  six  will  operate  the  UUVs.  [Trieble,  2001] 

2.2.3  Current  UUV  Technology 

In  June  of  2001,  the  VSW  MCM  Detachment  received  and  began  operating  two  underwa¬ 
ter  remotely  operated  vehicles.  These  vehicles  are  variants  of  the  Woods  Hole  Oceanographic 
Institute  (WHOI)  Remote  Environmental  Monitoring  UnitS  (REMUS). 


Figure  1 .  WHOI  REMUS  vehicle. 

REMUS  is  a  low-cost  autonomous  underwater  vehicle  (AUV)  developed  by  the 
WHOI  Oceanographic  Systems  Laboratory  for  coastal  monitoring  and  multiple 
vehicle  survey  operations  [WHOI].  The  REMUS  vehicle  weighs  120  pounds,  is 
powered  by  lithium-ion  batteries,  and  can  be  deployed  and  recovered  from  a  small 
boat  by  two  people.  It  navigates  by  orienting  to  a  grid  defined  by  pre-located  pingers, 
which  may  be  placed  by  divers  or  surface  craft.  The  vehicle  locates  mines  using  side¬ 
scanning  sonar.  A  map  is  created  by  downloading  sensor  data  only  upon  recovery  of 
the  vehicle.  The  vehicle  has  no  obstacle  avoidance  capability,  so  it  can  be  lost  upon 
collision  with  an  obstacle.  [Trieble,  2001] 
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2.2.4  Limitations  of  Current  Procedures 


Mine  countermeasure  operations  are  extremely  hazardous  to  personnel.  The 
underwater  environment,  even  without  the  presence  of  lethal  explosives,  is 
unforgiving.  Cold  water  limits  the  time  divers  may  operate.  Buried  mines  cannot  be 
located.  Once  set,  the  clocks  in  the  mine  neutralization  charges  can  neither  be  reset 
nor  suspended.  There  is  no  capability  to  remotely  synchronize  the  activation  of  the 
charges.  [Trieble,  2001] 

Nighttime  operation,  necessitated  by  the  likely  presence  of  hostile  forces  near  the  beach, 
significantly  reduces  visibility,  defeating  man's  primary  sensory  capability.  Passive  IR  and 
other  night-vision  equipment,  which  are  relatively  inexpensive  and  widely  available,  could 
expose  the  small  boats  and  divers  and  eliminate  the  night  operation  advantage.  Sonar 
receivers  and/or  bioluminescence  products,  if  placed  in  the  minefields,  could  detect  the 
operation  of  the  marine  mammals  and  human  divers. 

The  present  UUV  (REMUS)  requirement  for  pre-placed  acoustic  grid  markers  imposes  an 
additional  burden  upon  human  operators.  Loss  of  function  of  any  acoustic  grid  marker  could 
disable  the  mapping  capability  of  the  UUV. 
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3.  OUTSTANDING  ISSUES  FROM  PREVIOUS  UUV  EFFORTS 


This  Section  presents  questions  and  unresolved  issues  from  previous  UUV  efforts  in  an 
attempt  to  highlight  the  pressing  operational  problems  and  technology  needs  that  might  be 
unique  to  the  VSW  environment. 

3.1  UUV  OPERATIONS 

3.1 .1  A  UUV  Concept  of  Operations  in  VSW  Reconnaissance  Missions 

It  is  often  useful  in  any  investigation,  though  often  a  little  irritating,  to  start  with  a  few 
questions.  These  questions  must  go  beyond  the  simple  "what  is  the  problem?",  for  to  solve 
any  problem,  one  must  know  something  of  its  mechanisms  or  contributing  factors. 

But  first,  let  us  begin  with  a  restatement  of  the  problem. 

It  is  cheaper  to  build  a  mine  than  it  is  to  build  a  countermeasure,  and  faster  to  build  a 
new  mine  than  a  new  countermeasure.  The  miner  seems  to  have  the  advantage  in 
staying  ahead  in  this  loop.  [Jones,  2000] 

Amphibious  landings  have  been  effectively  practiced  since  at  least  the  time  of  Homer,  and 
probably  go  as  far  back  as  the  invention  of  the  boat.  The  defenders  of  the  beach  have  used 
missiles,  obstacles,  and  fire  to  discourage  those  landings.  Today,  mines  of  all  types,  placed  in 
sequence  from  deep  water  to  beyond  the  surf  line,  make  the  transit  from  the  deep  water  to  the 
land  very  hazardous.  The  mines  can  detonate  on  contact  and  on  approach  using  various 
clever  sensors.  As  it  is  physically  difficult  to  mask  one's  signature  and  harder  still  to  be 
immaterial  without  first  encountering  a  mine,  the  mine  seems  to  have  the  tactical  advantage. 

Since  mines  are  themselves  material,  the  standard  approach  has  been  to  exploit  the  mine's 
signature  and  after  detecting  it,  to  avoid  it,  or  to  neutralize  it.  Our  objective  has  been  to 
develop  better  signature-recognition  devices  in  our  MCM  equipment  than  the  opposition 
forces  have  in  their  mines,  thus  getting  inside  the  opposing  information  loops.  One  difficulty, 
however,  is  that  the  mine’s  reason  for  being  is  to  self-destruct  upon  recognition  of  its  target. 
The  mine  can  afford  to  make  one  false  positive  error,  but  we  cannot  afford  to  make  one  false 
negative  error.  Again,  the  mine  seems  to  have  the  advantage. 

Is  there  a  way  to  use  the  nature  of  the  mine  to  our  advantage?  Or,  to  put  the  question 
another  way,  is  it  always  operationally  appropriate  to  activate  or  neutralize  a  mine  just  before 
our  advance  through  the  field?  We  could,  for  example,  under  certain  circumstances,  find  it 
expedient  to  activate  or  otherwise  neutralize  mines  as  they  are  laid.  Just  a  few  seemingly 
random  and  ill-timed  activations  could  significantly  disrupt  the  mine-field  seeding 
operations.  This  disruption  would  require  a  pre-deployment  of  the  MCM  agent.  But,  however 
we  answer  that  question,  we  still  must  detect  and  neutralize  a  mine. 
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Following  are  a  few  other  relevant  questions  on  detection  and  neutralization: 

Some  preliminary  questions  on  Detection : 

V  Is  the  system  required  to  detect  individual  VSW  mines  or  is  the  concept  to 
clear  a  path  without  necessarily  detecting  individual  mines?  I  think  the 
JAMC  program  was  doing  the  latter  at  least  on  the  beach. 

V  If  detection  of  individual  mines  is  required,  do  we  know  what  sensors  can 
accomplish  this  with  high  reliability,  the  characteristics  of  these  sensors,  and 
the  operating  conditions  necessary  for  successful  performance?  The  answers 
are  likely  to  drive  the  systems. 

V  How  can  the  water  movement  in  the  surf  area  affect  detection  (for  better  or 
worse)? 

V  To  what  extent  can  the  detection  process  be  automated  successfully? 

[Schwartz,  2000] 

Some  questions  on  Neutralization'. 

N  Will  VSW  mines  be  neutralized  individually?  At  the  place  where  they  are 
located?  If  so,  how? 

V  If  not,  how  will  neutralization  be  accomplished?  [Schwartz,  2000] 

Some  questions  on  Tactical  Situation  Parameters'. 

N  Is  this  a  combat  scenario  as  opposed  to  peacetime  de-mining  operation? 

V  If  so,  what  constraints  does  (possible)  enemy  presence  impose  (e.g.,  on 
explosive  neutralization)?  [Schwartz,  2000] 

While  implicit  in  the  above  questions,  a  couple  of  additional  questions  may  be  raised: 

■  What  are  the  schedule  constraints  between  the  deployment  of  the  MCM  assets,  the 

verification  of  a  clear  lane,  the  clearance  of  a  mined  lane,  and  the  use  of  either 

lane? 

■  Is  it  strategically  permissible  to  discourage  or  prevent  the  distribution  of  mines  prior 

to  any  tactical  use  of  the  lane? 

Answers  to  the  above  questions  can  help  guide  the  development  of  the  concept  of 
operations  for  a  VSW  MCM  UUV. 

3.1 .1.1  Steps  in  the  Mine  Hunting  Process 

The  mine-hunting/clearing  process  is  logically  divided  into  seven  primary  tasks: 

1.  Deployment  and  distribution  of  assets 

2.  Execution  of  a  search  strategy 

3.  Detection  of  mine-like  objects 

4.  Classification  and  identification 

5.  Neutralization 

6.  Verification  or  certification  of  clearance 

7.  Recovery  of  assets. 
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To  ensure  that  the  mine  clearance  is  complete,  the  sequence  above  may  need  to  be 
repeated  several  times,  depending  upon  the  level  of  acceptable  risk.  The  current  use  of 
dolphins  for  detection  and  divers  for  identification  and  neutralization  requires  that  some  but 
not  all  of  the  steps  be  repeated.  For  example,  the  target  objects  (candidate  mines  and 
obstacles)  must  be  acquired  twice,  once  by  the  dolphins  and  once  again  by  the  divers. 

3.1 .1.2  The  Deployment  of  One  Complex  or  Many  Simple  Vehicles 

If  only  one  very  competent  agent  was  assigned  to  accomplish  the  above  sequence,  we 
must  assume  that  it  would  be  quite  valuable  (as  are  divers  and  dolphins),  requiring  the 
completion  of  all  steps  through  recovery,  and  returning  the  cost/benefit  advantage  to  the 
inexpensive  mines.  The  assignment  of  a  few  of  such  agents  would  not  materially  change  this 
situation. 

If,  on  the  other  hand,  many  relatively  incompetent  and  yet  inexpensive  agents  could  be 
used  for  mine  hunting/clearing,  then  we  may  not  have  to  accomplish  all  the  steps  above. 
Definitely,  we  would  need  to  perform  steps  1  and  5,  and  quite  likely,  6,  but  detection, 
classification,  and  recovery  could  be  inconsequential  if  the  many  cheap  agents  could  clear  the 
lane  of  mines. 

A  Massachusetts-based  company,  iRobot,  an  outgrowth  of  Professor  Rodney  Brooks' 
work  on  subsumption  architectures  at  the  Massachusetts  Institute  of  Technology  (MIT),  has 
developed  a  crab-like  robot,  the  Ariel  Autonomous  Legged  Underwater  Vehicle  (ALUV),  for 
mine  and  obstacle  neutralization. 

In  an  amphibious  assault  operation,  a  fleet  of  these  expendable  bottom  crawlers  are 
deployed  to  collectively  search  a  zone.  Each  will  find  and  secure  itself  next  to  a  mine, 
then  wait  for  a  detonation  signal.  For  non-destructive  operation,  modifications  can  be 
made  to  allow  the  robots  to  deposit  an  explosive  in  a  predetermined  location  and 
move  to  safety  before  detonation.  [iRobot] 

Questions  remain  on  how  the  ALUV  would  find  the  mines,  maintain  an  efficient  search  of 
the  designated  lane,  and  find  their  way  safely  out  of  the  search  area  if  recovery  was  required. 

A  modification  of  the  iRobot  approach  could  have  the  ALUV-like  agents  distribute 
themselves  over  the  lane  with  a  density  sufficient  to  neutralize  all  resident  mines  and 
obstacles.  A  "brute-force"  approach  is  again  contemplated  here. 
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Figure  2.  iRobot's  Autonomous  Legged  Underwater  Vehicle. 

There  are  two  crucial  questions  that  must  be  adequately  addressed  with  the  use  of  all  of 
the  approaches  that  use  sensor/capability-limited  agents:  (1)  would  the  clearance  be 
complete,  and  how  would  we  assess  this?  and  (2)  what  would  we  do  with  our  own 
unexploded  ordnance  (UXO)  that  could  survive  this  process? 

There  are  other  approaches: 

There  are  two  possible  concepts  for  both  crawling  and  swimming  UUVs  for  mine 
detection.  The  first  possible  concept  of  operations  for  using  robotic  systems  in  a 
VSW  environment  would  be  to  employ  a  moderate  number  (6-12)  vehicles  in  a 
collaborative  mode  to  'swarm'  onto  a  target.  In  this  concept,  the  UUVs  have  a  very 
basic  collaborative  algorithm  that  simplifies  navigation  and  would  use  a  magnetic 
detector  to  help  each  other  find  the  target.  I'm  not  sure  how  well  this  would  work  in  a 
multiple  target  environment,  however.  (SANDIA  LABS  have  been  doing  some  work 
in  this  field).  The  other  concept  is  to  use  one  or  many  robots  to  search  and  detect 
mines.  In  this  case,  each  robot  is  independent  of  the  others  and  could  use  a  pattern  or 
random-search  methodology  to  cover  an  area.  This  concept  would  work  better  in  a 
multi-target  situation,  and  probably  require  fewer  systems,  but  would  require  more 
complicated  robots.  [Clemons,  2000] 

The  basic  question  here  is  whether  to  assign  one  or  more  vehicles  to  the  task.  Since  the 
task  is  distributed  (there  are  many  mines  in  the  VSW/SZ  and  possibly  many  different  types  of 
mines  and  obstacles  deployed),  an  assignment  of  many  vehicles  with  different  capabilities 
may  be  preferred  to  the  assignment  of  one  multipurpose  vehicle.  Task  completion  time  can 
be  decreased,  of  course,  with  increased  numbers  of  resources  applied  in  parallel.  The  current 
operational  process  of  draping  a  mesh  of  distributed  charges  over  a  minefield  in  the  SZ  or  on 
the  beach  to  clear  a  lane  is  a  very  simple  example  of  a  distributed  solution,  while  the  current 
practice  of  using  dolphins  for  detection  and  humans  for  classification  is  an  example  of  the 
multi-agent  approach. 

The  specific  technical  requirements  for  logistics,  power  densities,  sensor  configurations, 
communications,  and  control  capabilities  will  vary  depending  upon  how  the  seven  primary 
MCM  tasks  are  allocated  among  the  several  vehicle  types.  The  fundamental  advantages  of 
the  application  of  multiple  agents,  however,  are  in  speed  and  in  reliability  of  mission 
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completion,  that  is  -  in  overwhelming  power.  The  fundamental  disadvantage  is  in  cost.  When 
costs  per  agent  could  be  sufficiently  reduced,  as  was  historically  the  case  with  the  common 
foot  soldier,  the  economics  of  combat  was  simply  the  more  the  better. 

But  all  is  not  so  simple,  for: 

It  is  a  mistake  to  think  that  intelligent  group  behavior  will  emerge  from  a  collection 
of  simple  robots  [Albus,  2001] 

To  achieve  useful,  if  not  intelligent,  group  behavior  from  a  collection  of  simple  robots, 
some  very  smart  planning  and  clever  programming  may  have  to  be  performed  in  advance  of 
the  deployment. 

The  goal  of  the  Swarm  project  at  IS  Robotics  is  to  develop  techniques  for 
programming  a  distributed  group  of  autonomous  robots.  Programs  for  individual 
robots  need  to  be  robust  in  the  face  of  complex  environments,  and  the  group  software 
needs  to  be  tolerant  to  the  failure  of  any  number  of  individuals.  The  algorithms 
developed  must  be  designed  to  be  completely  scaleable,  that  is  to  function  with 
groups  of  10  or  groups  of  10,000.  [iRobot] 

A  strict  either/or  choice  in  the  question  of  one  complicated  agent  versus  many  simple 
agents  may  not  be  the  best  way  to  have  asked  the  question,  for  there  are  other  alternatives. 

NAVEODTECHDIV  is  pursuing  a  somewhat  similar  problem,  namely  clearing  large 
quantities  of  small  UXO  (bomblets).  They  are  working  on  two  concepts,  both  of 
which  involve  a  significant  number  of  small  UGVs  operating  simultaneously  within  a 
target  area.  The  small  UGVs  are  thought  of  as  semi-expendable.  In  one  concept,  the 
small  UGVs  perform  either  a  random  search  or  a  pattern  search  and  when  a  UXO  is 
found,  act  to  neutralize  it  (representing  a  potential  trade  in  thoroughness  for  speed). 

In  the  second  concept,  a  single  large  UGV  searches  for  and  locates  the  UXOs  after 
which  the  small  UGVs  are  dispatched  to  neutralize  them  (representing  a  potential 
trade  in  cost  efficiency  and  in  speed  for  thoroughness).  A  variant  of  this  latter 
concept  might  be  to  have  the  large  UGV  release  a  small  UGV  whenever  a  UXO  is 
found.  There  is  some  interest  in  "marsupial"  robots  these  days  and  the  DARPA 
Tactical  Mobile  Robotics  program  has  done  some  work  in  this  area.  [Schwartz, 

2001] 

The  marsupial  concept  has  several  advantages.  The  "mother"  robot  could  provide  not  only 
transportation,  but  also  computation,  power,  and  communications  support,  in  some  respects 
substituting  for  human  support  personnel. 

The  next  Figure  shows  an  early  marsupial  application  involving  the  MDARs-E  platform 
as  the  "mother"  and  the  MPRS  URBOTt  as  the  deployable  element.  The  gas-powered 
MDARS-E  platform  transports  the  battery-powered  MPRS  URBOT  to  a  RSTA  site  where  the 
URBOT  is  released  to  provide  high-risk  target  acquisition  and  laser  designation.  Operators 
drive  the  remote  URBOT  using  communications  relayed  through  the  intermediately  located 
MDARS-E  platform. 


13 


Figure  3.  MDARS-E  and  MPRS  URBOT  in  a  "marsupial"  configuration. 

Another  variation  on  the  distribution  of  different  capabilities  between  non-equivalent  task 
agents  follows: 

The  sensing  pod  need  not  be  rigidly  attached  to  the  base  vehicle.  Nor  need  the 
communications  method.  Examples  could  be  floating  antenna,  pop-up  cameras, 
vehicles  could  be  tethered  to  each  other  in  pairs  or  by  snag  lines.  The  principle  is 
distributable  sensors  and  effectors.  The  distributed  elements  may  be  camouflaged  to 
appear  as  natural  objects  in  that  particular  environment.  Distributable  sensors  may  be 
less  expensive  than  moving  a  larger  vehicle.  They  may  be  abandoned.  They  may 
provide  multiple  perspectives,  they  may  not  require  much  in  the  way  of  machinery 
and  power.  [Schempf,  2001] 

As  is  often  the  case,  the  feasible  solution  may  be  a  compromise  between  the  many  factors 
from  the  different  domains  of  operations,  programmatics,  and  technologies.  An  important 
lesson,  however,  is  to  try  to  avoid  adherence  to  any  particular  solution  or  process  model,  for 
other  solutions  may  be  admitted  following  the  relaxation  of  a  constraining  factor  from  among 
any  of  the  domains. 

3.1.2  Target  Localization  and  Mapping  Techniques 

Mapping  involves  establishing  both  the  frames  of  reference  and  the  rules  for  transforming 
the  locations  of  objects  between  those  frames  of  reference.  When  the  locations  of  the  objects 
in  both  of  the  frames  of  reference  are  unknown,  then  methods  of  target  localization  must  be 
developed  and  applied.  Target  localization  is  the  first  problem  of  mine  hunting. 

Looking  for  the  mine  where  it  is  most  likely  to  be  found  is  a  good  way  to  start,  but  one 
must  first  establish  a  frame  of  reference  for  that  territory.  The  absence  of  our  customary 
natural  frames  of  reference  under  water  contributes  to  the  difficulties  we  have  in  navigation 
and  mapping  there. 

A  TOV  underwater  is  very  difficult  to  navigate  as  there  are  no  horizon  or  other 
landmarks  for  orientation.  Disorientation  should  be  expected.  [Schempf,  2001] 
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Thus,  underwater  we  see  no  horizon,  we  see  no  GPS,  we  do  not  see  very  much  at  all.  For 
this  reason,  existing  operations  pre-position  sound-reference  beacons  to  provide  landmarks. 

If  this  pre-positioning  of  reference  posts  is  impractical  for  whatever  reason,  then  what  are 
the  alternatives?  One  possibility  could  be  the  positioning  of  reference  posts  on  the  fly,  that  is, 
in  the  process  of  mapping.  An  agent  in  the  beginning  of  a  map  operation  might  deposit  its 
reference  posts  in  the  best  configuration  that  it  can,  and  then  work  within  its  own  grid. 

Another  possibility  could  be  that  once  in  the  area  to  be  mapped,  the  diver  or  vehicle  might 
"look  around"  with  sonar  to  find  local  references.  This  process  could  succeed  if  there  were 
two  or  more  detectable  sonar  landmarks.  Fixed  obstacles  would  be  ideal  for  this  purpose,  for 
they  should  describe  a  unique  pattern  of  placement  relative  to  the  slope  to  the  beach.  Then  as 
the  agent  moves  through  the  area,  it  could  continue  to  take  sonar  bearings  from  those 
landmarks,  and  with  the  aid  of  an  inertial  navigation  system  (INS)  and  a  compass,  map  the 
relative  locations  of  its  way-points.  The  agent  would  calculate  how  the  sonar  bearings  would 
change  as  it  moved  relative  to  its  landmarks.  The  confirmation  of  this  calculation  with  the 
actual  sonar  returns  would  tell  the  agent  where  it  was  located.  This  calculation  would  be  a 
computationally  intensive  process,  but  quite  within  the  capabilities  of  current  technologies 
for  either  a  manned  or  unmanned  system. 

Beyond  the  solution  to  the  problem  of  navigation  and  mapping,  one  must  decide  how  best 
to  search  the  area.  Possible  criteria  for  a  good  search  include: 

■  Coverage — how  much  of  the  territory  is  actually  searched? 

■  Detail — how  many  different  types  of  targets  are  catalogued? 

■  Speed — how  quickly  can  the  search  be  completed  according  to  the  two  previous 
criteria? 

Any  of  the  search  criteria  can  be  traded  in  favor  of  the  other  two. 

In  addition,  a  search  pattern  can  be  governed  by  either  one  or  both  of  two  basic  factors: 

■  Intrinsic — internal  rules  that  plan  and  control  the  search. 

■  Extrinsic — external  conditions  that  control  the  search. 

Intrinsic  factors  are  often  considered  to  be  intentional  or  systematic,  while  extrinsic 
factors  are  often  considered  to  be  random. 

Random  search  patterns  are  not  efficient.  [Schempf,  2001], 

The  environment  is  not  random,  which  could  defeat  a  random  search  pattern.  [Albus, 

2001] 

In  nature,  the  first  sensors  developed  in  marine  animals  were  for  chemicals,  light,  and 
gravity.  With  these  simple  sensors,  agents  could  find  and  discriminate  relevant  targets,  and 
orient  with  respect  to  the  vertical,  which  facilitated  navigation.  To  the  degree  that  the  stimuli 
activating  those  three  types  of  sensors  (and  thus  controlled  the  behavior  of  the  animal)  were 
regular  and  consistent,  the  animal  appeared  to  behave  systematically.  Memory,  a  much  later 
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addition,  improved  the  consistency  of  behavior  in  complex  (para-random)  and  simple 
environments. 

The  locking  of  the  search  pattern  to  an  extrinsic  event  can  create  the  appearance  of 
randomness  if  the  event  is  unpredictable,  but  can  also  create  the  appearance  of  consistency 
otherwise.  If  the  object  of  the  search  provides  a  reliable  and  detectable  factor,  then  locking 
the  search  pattern  to  that  factor  might  be  a  good  idea.  Whether  the  pattern  was  random  or 
systematic  would  not  matter  in  such  a  case  if  all  of  the  search  objects  were  found.  Counter¬ 
mine  countermeasures,  of  course,  will  attempt  to  mask  all  such  factors. 

The  information  available  to  a  tidewater  UUV  may  be  greater  than  our  own  experience 
permits  us  to  presume. 

Consider  multi-resolution  maps:  Perform  multilevel  planning  by  time  frame  and  by 
other  time  dependent  factors.  Can  monitor  wave  and  tide  action  using  pressure  and 
flow  sensors,  and  plan  behaviors  accordingly.  [Albus,  2001] 

Obviously,  orienting  is  a  major  aspect  of  mapping.  Similarly,  searching  is  a  major  aspect 
of  orienting.  Some  of  the  earliest  examples  of  mapping  in  nature  are  the  abilities  of 
arthropods  such  as  bees  and  ants  to  find  their  way  to  and  from  sources  of  food  and  the  nest. 
These  species  search  for  key  stimuli — a  chemical  trail,  or  the  position  of  the  sun.  They  then 
orient  to  the  key  stimulus  and  maintain  that  orientation  during  their  excursions.  Bees  can 
communicate  their  maps  to  other  bees.  There  is  evidence  that  ants  behave  similarly.  These 
species  definitely  depend  upon  group  action  for  survival,  thus  maps  are  critical  to  the 
coordination  of  several  otherwise  independent  searches.  At  the  next  level  of  the  phylogenetic 
scale,  however,  the  mollusks  (snails,  slugs,  and  octopuses)  that  generally  live  solitary  lives, 
also  use  maps  to  navigate.  We  may  be  able  to  follow  the  suggestion  of  Albus  by  applying  the 
elementary  mapping  capabilities  of  arthropods  and  mollusks  to  simple  UUVs  in  the 
VSW/SZ.  After  identifying  the  key  orienting  features  of  that  environment,  the  simple  UUVs 
could  then  create,  use,  and  communicate  maps  to  their  co-specifics. 

3.1 .3  Operational  Logistics  and  Supportability  Issues 

Smaller  entities  tend  to  be  less  expensive  under  all  measures  of  cost  (  yachts,  dinosaurs, 
UUVs,  and  computer  software  are  familiar  examples  of  this  truth). 

Smaller  of  everything  (except  on-board  intelligence  or  processing  capability,  and  on¬ 
board  power)  was  better  because  support  requirements  were  much  reduced.  [Walton 
and  Uhrich,  1995] 

Small  inexpensive  agents  require  less  maintenance  support  because  they  can  be  replaced, 
but  the  need  for  replacements  can  add  to  the  logistics  load.  Agents  of  the  approximate  size  of 
man  are  easier  to  work  on  as  the  components  may  be  just  large  enough  to  see  with  unaided 
vision,  and  just  large  enough  to  manipulate  by  hand.  This  size  is  an  advantage  if  in-service 
maintenance  is  desirable.  The  main  advantage  of  the  largest  agents  is  that  their  maintenance 
requirements  are  generally  less  following  collisions  with  the  smaller  agents. 

Obviously,  the  task  circumstances  should  determine  the  appropriate  size  for  an  agent. 
Those  agents,  for  example,  that  must  operate  in  man's  environment,  using  man's  hand  tools 
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and  negotiating  human  spaces,  must  scale  to  the  dimensions  of  man.  On  the  other  hand,  man 
has  developed  tools  across  many  scales,  some  quite  large  and  powerful,  others,  quite 
miniature.  The  integration  of  controller  and  tool  could  result  in  agents  at  all  those  scales. 

Small  agents  require  refueling  more  often  than  large  agents.  Often,  however,  the  low 
power  reserve  of  small  agents  can  be  compensated  with  cooperating  numbers. 

Generally,  the  cheaper  a  product,  the  more  abundant  it  becomes.  This  abundance  can 
contribute  to  the  VSW  MCM  solution  and  to  its  problem.  Therefore,  the  proliferation  of 
small,  inexpensive,  and  adaptive  agents  must  be  controlled;  otherwise,  they  will  surely 
appear  as  mines. 

3.1 .4  Concepts  of  Deployment/Recovery 

Deployment  and  recovery  of  UUVs  in  non-military  contexts  are  not  burdened  by  the  need 
for  covert  operations,  but  are  still  troubled  by  all  the  problems  of  dealing  with  the  sea  and 
with  the  weather.  As  with  other  aspects  of  logistics,  vehicle  size  is  a  factor.  Smaller  vehicles 
are  easier  to  handle  than  larger  vehicles.  But  smaller  vehicles  must  be  placed  in  proximity  to 
their  targets  for  lack  of  endogenous  sustaining  energy. 

How  to  address  power  density?  Batteries  do  not  have  adequate  staying  power;  best  to 
avoid  fighting  gravity;  air  deployment  is  more  efficient  than  water  deployment. 

[Schempf,  2001] 

Air  deployment  generally  precludes  covert  operations  and  raises  the  question  of  air 
recovery,  but  it  may  work  effectively  as  part  of  an  in-stride  clearance  operation.  After  which, 
recovery  could  be  accomplished  at  leisure. 

If  the  agents  do  not  have  to  be  recovered,  reserve  power  requirements  are  reduced. 

3.2  PROGRAMMATICS 

3.2.1  Acquisition  Strategies 

The  commercial  UUV  product  appears  more  mature  than  the  UGV  product  because  the 
undersea  environment  is  more  hostile  to  man,  thus  motivating  the  markets  for,  and  then  the 
development  and  production  of  UUVs.  The  opportunities  for  commercial  participation  in  the 
VSW  MCM  acquisition  are  therefore  greater.  The  commercial  UUV  industry  also  has  a 
broader  base  favoring  competition. 

3.2.2  Performance  Parameters  and  Methods  for  Test  and  Evaluation 

A  major  problem  with  system-level  testing  in  the  Department  of  Defense  (DoD)  today  is 
that  we  can  almost  never  tolerate  failure.  Military  and  civil  service  careers,  company  profits, 
and  political  reputations  all  depend  upon  successful  acquisition  programs.  Thus,  measures  of 
performance  (MOP)  and  measures  of  effectiveness  (MOE)  are  nearly  always  set  to  levels  that 
are  inversely  proportional  to  the  probability  of  failure  of  the  system.  As  a  consequence, 
poorly  designed  systems  pass  their  tests,  that  is,  they  survive,  and  their  very  persistence 
contributes  to  the  replication  of  their  design  flaws  in  subsequent  systems.  Only  during  total 


17 


warfare,  when  other  careers  depend  upon  the  demonstration  of  the  vulnerabilities  of  our 
products,  does  it  become  apparent  to  us  what  works  and  what  does  not  work. 

Nature  has  been  much  more  efficient  through  the  processes  of  evolution  in  funding 
programs;  only  the  fittest  designs  survive.  While  one  could  say  that  warfare  is  pretty  much 
continuous  in  nature,  the  most  successful  natural  design  features  are  still  proven  in  that 
process  and  are  reproduced  again  and  again  in  all  variety  of  subsequent  organisms.  Recent 
discoveries  in  the  huge  overlap  in  Deoxyribonucleic  Acid  (DNA)  between  unicellular 
organisms  and  man  bear  this  out.  Another  example  of  the  preservation  of  working  designs  in 
nature  are  the  similarities  in  brain  organization  between  all  mammalian  species,  including 
man,  but  of  course,  the  origins  of  those  similarities  are  in  the  DNA. 

A  lesson  from  nature  for  developers  of  artificial  systems  could  be  that  unrestrained  "live- 
fire"  testing  should  occur  as  early  in  the  developmental  cycle  as  possible,  and  should  include 
efforts  of  opposing  (Red)  forces,  as  determined  as  would  be  real  competitors,  to  defeat  the 
proposed  design.  Then,  if  the  design  fails  to  survive,  measure  its  cost  of  production  against 
the  costs  to  the  enemy  to  defeat  it.  If  favorable,  then  let  it  continue;  if  unfavorable,  then  let  it 
become  extinct. 

But  even  a  good  design  can  suffer  from  bad  production. 

Nothing  substitutes  for  fundamentally  reliable  equipment  [Yoerger,  2001], 

Just  takes  extra  effort,  test  and  test  again.  [Yoerger,  2001] 

The  hardest  thing  is  to  get  everything  to  work  at  once:  things  that  fail  could  be  a 
latch,  a  motor,  a  connection.  The  underwater  environment  is  unforgiving.  [Yoerger, 
2001] 

3.2.3  System  Definition 

A  system  could  be  defined  at  many  different  levels  of  complexity  or  integration.  The 
control  system  may  be  composed  of  programs  that  manage  task  priorities,  sequencing, 
memory  and  access,  and  communications.  The  vehicle  is  a  system  of  components  that  may 
include  frame  and  chassis,  sensors,  motors  and  propulsion,  energy  sources,  communications, 
and  control  functions.  The  MCM  system  may  include  the  vehicle,  the  operators,  the  support 
craft,  the  navigation  buoys,  and  the  operational  environment  including  the  mines  and 
obstacles.  The  architecture  is  one  way  to  describe  the  system. 

Don't  waste  time  talking  about  architecture,  more  reliable  components  are  better. 

[Yoerger,  2001] 

Another  definition  of  reliable  is  survivable  (see  section  3.2.2). 

Keep  computer  scientists  out  of  the  project.  They  will  build  an  immense  software 
edifice  and  keep  mucking  with  it  forever.  It  will  take  10,000  CPU  cycles  to  add  1+1 
and  need  to  go  at  500MHz  to  have  the  through-put  to  talk  to  a  peripheral  that  is  only 
a  single-chip  8-bit  microcomputer.  Use  something  simple.  [Bradley,  2001] 
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There  is  a  tendency  on  the  part  of  researchers  to  reach  for  the  elegant  solution  when 
the  real  need  is  to  keep  developmental  efforts  as  simple  as  possible.  The  KISS 
principle  often  gets  overlooked.  It  seems  to  me  that  a  total  system  approach  would 
take  as  much  advantage  of  a  human  operator  as  possible.  [Jenkins,  2001] 

Most  AUV  designs  are  limited  by  power  available.  This  comes  out  in  the  first  "back 
of  the  envelope"  design  cycle.  Those  projects  that  then  panic  and  go  to  the  handbooks 
to  choose  "the  best  power  source"  rarely  allocate  enough  effort  to  taming  the  exotic 
choice  they  came  up  with.  There  are  enough  problems  to  face,  start  a  new  AUV 
design  with  a  simple  power  source.  When  it's  working,  then  you  can  update  the 
power  system.  [Bradley,  2001] 

Reliability  engineers  know  that  total  system  reliability  is  a  product  function  of  the 
reliabilities  of  the  critical  components.  As  component  cost  is  related  to  the  reliability 
requirement,  it  becomes  economically  impractical  to  demand  too  high  a  reliability  for  any 
one  component.  An  alternative  to  achieving  high  system  reliability  through  high  component 
reliability  is  to  reduce  the  number  of  critical  components.  This  reduction  can  be 
accomplished  either  through  simplification,  or  through  redundancy.  Since  redundancy  is  also 
expensive,  simplification  is  preferred,  as  above. 

However,  as  much  as  simplification  is  desirable,  there  are  few  real-world  working 
examples  of  simple  systems.  From  the  realm  of  elementary  particles,  to  the  metabolism  of  an 
amoeba,  to  the  modulation  of  temperature  in  the  atmosphere,  real  systems  are  very  complex, 
with  lots  of  feedback  and  feed-forward  among  the  components.  We  need  a  way  to  understand 
this  complexity.  Describing  the  system  architecture  with  its  information  exchange 
requirements  is  one  way. 

There  are  several  ways  to  define  simple  in  the  context  of  robotics  applications.  Our 
common  conception  of  simple  is  something  that  is  singular,  basic  or  fundamental,  and  easy. 
(We  also  use  simple  when  we  mean  stupid  and  naive.)  So  far,  the  uses  in  this  report  have 
suggested  that  a  few  lines  of  code  are  simple,  a  few  system  components  are  simple,  and  a 
limited  functional  capability  is  simple,  perhaps  as  a  consequence  of  the  first  two  uses  listed  in 
this  sentence.  We  must  admit,  however,  that  simplicity  is  an  illusion  based  upon  to  what  we 
are  paying  attention,  for  if  something  works  well,  no  matter  how  internally  complex  it  is,  we 
can  ignore  it. 

A  simple  solution  is  an  adequate  solution.  [Hudson,  2001] 

A  robot  may  be  of  any  degree  of  internal  complexity  as  long  as  its  demands  on  the 
user  are  simple.  [Hudson,  2001] 

Another  way  to  look  at  the  simplicity  of  a  solution  is  to  consider  its  compatibility  with  the 
remaining  infrastructure,  which  is  implied  in  the  last  definition  by  Hudson.  The  questions  to 
be  asked  are  as  follows: 

■  Does  the  solution  meet  the  requirements? 

■  Does  it  violate  any  of  the  requirements? 

■  Does  it  reduce  the  total  costs  of  doing  business? 
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A  simple  solution,  then,  makes  life  easier  in  all  measures  for  the  user.  A  complex  solution, 
by  contrast,  is  one  that  has  the  potential  to  increase  workload  and  costs. 

3.2.4  Other  Programmatic  Issues 

As  a  consequence  of  the  first  autonomous  underwater  search  system  (AUSS) 
prototype  in-ocean  testing,  the  most  significant  lessons  were  learned.  These  lessons 
resulted  in  major  evolutionary  changes  to  the  design.  Only  after  those  design  changes 
were  implemented  was  system  feasibility  demonstrated.  By  that  time,  the  technology 
employed  in  the  prototype  had  become  outdated.  Sea  tests,  modifications  or 
evolutions  to  operations  and  tactics,  and  modifications  or  evolutions  to  design  and 
implementation  became  synergistic  and  interactive.  Thus,  two  prototypes  were 
required.  One  lesson  is  that  the  system  must  be  designed  to  accommodate  rapidly 
evolving  technologies  -  modularity  would  help  here.  Another  lesson  learned  is  that 
the  system  such  as  AUSS  (where  the  operational  environment  is  not  well  understood) 
must  be  developed  interactively  with  the  user  and  in  the  operational  environment  as 
much  as  practical.  [Walton  and  Uhrich,  1995] 

The  UUV  industry  has  produced  several  commercial  products  for  deep-water  operation. 
Much  of  this  technology  is,  of  course,  directly  applicable  to  the  VSW  UUV  applications. 
Examples  are  as  follows: 

V  Commercial  UUVs:  deep  water  Maridan  600  cost  from  $1.5M  to  $2M  (Maridan 
of  Denmark);  Hugin  (Kongsberg  Simrad/Statoil  of  Norway. 

V  Navy  mine-hunting  UUV:  Long-Term  Mine  Reconnaissance  System  (LMRS) 
scheduled  for  initial  operation  in  2003. 

V  Royal  Navy  mine-hunting  UUV:  Marlin,  developed  by  BAE  Systems  for  the 
Defense  Evaluation  and  Research  Agency,  in  operational  evaluation  in  2001. 

V  Academic  UUVs:  Woods  Hole— REMUS  (~$175K);  MIT— Odyssey, 
w/Lockheed  Martin — Cetus  II  ($45 K) ;  Florida  Atlantic  University —  Morpheus. 

[Wernli,  2000] 

Table  2  lists  web  sites  for  many  UUV  producers  [Wernli,  2000]. 
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Table  2.  Internet  addresses  of  UUV  producers. 


URL 

Vendor 

www.dw-l.com 

Douglas- Westwood  Associates 

w  w  w .  maridan .  dk 

Maridan  A/S 

www.cctechnol.com 

C&C  Technologies 

www.kongsberg-simrad.com 

Kongsberg  Simrad 

www.racal-survey.com 

Racal  Survey 

www.bluefinrobotics.com 

Bluefin  Robotics  Corporation 

www .  fgsi .  fugro  .com 

Fugro  GeoServices  Inc. 

www.ise.bc.ca 

International  Submarine  Engineering  Ltd. 

www.oceanscan.co.uk 

Oceanscan  Ltd. 

www .  k-marine  .co.jp 

Kodusai  Marine  Engineering  Corp. 

www.whoi.edu 

Woods  Hole  Oceanographic  Institute 

www.soc.soton.ac.uk/autosub/ 

Southampton  Oceanography  Centre,  Autosub 

www . j  amstec .  go . j  p 

JAMSTEC 

http  ://underwater  .iis  .u-tokyo .  ac  .jp/W  elcome- 
e.html 

Tokyo  U.,  Ura  Lab. 

http://www.oe.fau.edu/AMS/auv.html 

Florida  Atlantic  University  AUVs 

http://auvserv.mit.edu/ 

MIT  AUV  Lab 

An  interesting  commercial  website  that  contains  much  useful  information  on  unmanned 
underwater  vehicle  technologies  may  be  found  at  [ISE], 

An  even  larger  list  of  vehicles  and  associated  technologies  specifically  oriented  to  the 
MCM  missions  is  available  from  [Fletcher,  1999]1.  Besides  a  complete  listing  of  vehicles 
that  have  been  developed  and/or  applied  to  the  MCM  tasks,  Fletcher  provides  useful 
comparisons  among  UUV  energy  sources,  communication  modes,  methods  of  navigation, 
sensor  capabilities,  and  mine  neutralization  strategies. 

Most  attention  given  to  ROV  and  AUV  MCM  efforts,  however,  have  addressed  either  the 
shallow-water  or  deep-water  mine  problems.  The  closer  one  attempts  to  drive  the  UUV  to  the 
beach,  the  greater  the  sensing,  navigation,  communication,  and  control  problems  become. 
Even  in  deeper  water,  Fletcher  notes  that  all  but  one  of  the  Fleet-deployed  systems  today  are 
ROVs.  The  benefit  of  the  ROV  is,  of  course,  that  the  human  is  removed  from  the  site  of  the 
action,  but  human  labor  is  not  reduced,  and  it  may  actually  be  increased  by  the  difficulty  of 
task  execution  from  a  distance.  Thus,  the  principal  shortcoming  of  a  ROV,  whether  on  land, 
in  the  air,  or  in  the  sea,  is  that  at  least  one  human  must  continually  monitor  and  control  each 
ROV.  Considerable  information  must  be  transferred  from  the  ROV  to  the  operator  to  make 
effective  remote  control  possible.  If  the  information  is  changing  rapidly,  as  it  does  in  the 
complex  terrestrial  environment  and  near  the  beach,  or  if  the  information  is  restricted,  as  it 
often  is  in  the  underwater  environment,  the  challenges  of  purely  teleoperated  control  can 
become  task-prohibitive. 


1  Barbara  Fletcher.  1999.  “Worldwide  Mine  Countermeasure  (MCM)  Vehicles  and 
Technologies.”  Report  submitted  to  the  Office  of  Naval  Intelligence.  September.  Contact 
author  at  SSC  San  Diego. 
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3.3  TECHNOLOGIES 


RADM  Kemp,  PEO,  Mine  and  Undersea  Warfare,  summarized  the  current  outstanding 
technology  issues  in  mine  countermeasures  that,  in  part,  motivate  the  present  project: 

V  Buried  mined  detection 

V  Pressure  mine  sweeping 

V  Cost 

V  Precise  underwater  navigation 

V  Data  fusion  for  the  common  tactical  picture 

V  VSW/SZ  operations 

V  Stand-off  neutralization  [Kemp,  2000] 

The  reasons  for  these  shortfalls  in  VSW/SZ  MCM  capability  are  attributable  primarily  to 
the  turbulence  of  the  water  near  the  beach,  and  to  the  difficulties  of  sensing  and 
communications  in  this  environment.  We  will  review  these  issues  in  the  following  sections. 

3.3.1  Sensor  Technologies 

SPAWAR  Systems  Center,  San  Diego  (SSC  San  Diego)  has  produced  for  the  Office  of 
Naval  Intelligence  (ONI)  a  survey  of  sensor  technologies  available  for  MCM  operations 
[Fletcher,  2000]2.  Sensor  types  covered  include  electro-optic,  acoustic,  and  magnetic. 

Acoustics  are  very  difficult  in  the  VSW/SZ  due  to  air  bubbles,  sand,  and  wave  action. 
Multi-path  is  significant.  Higher  frequency  acoustics  provide  better  resolution.  Most 
of  the  effort  will  be  in  signal  processing  due  to  the  problems  with  acoustics  in  the 
VSW/SZ.  [Schempf,  2001] 

Much  has  been  done  in  the  DoD  community  (including  target  classification  for  the 
shallow-water,  near-shore  security  arena)  in  the  field  of  sonar  data  processing. 

Utilize  the  results  of  this  work  instead  of  developing  new  sonar  data  processing  and 
classification  capabilities.  [Heath-Pastore,  2001] 

Chemical  detectors  should  also  be  considered  for  mine  detection  and  classification.  Both 
DARPA  [DARPA01]  and  ONR  [ONR01]  are  programming  resources  that  may  be  leveraged 
to  explore  this  possibility. 

3.3.2  Communications  and  Control  Methodologies 

The  experts  from  WHOI  and  elsewhere  with  whom  we  interviewed  were  unanimous  in 
their  opinion  that  acoustic  communications  are  very  difficult  in  the  VSW/SZ.  Without 
reliable  high-bandwidth  communications,  external  control  will  be  difficult.  Some  other 
strategies  for  communications  were  suggested,  however. 


2  Barbara  Fletcher.  2000.  “Worldwide  Mine  Countermeasures  (MCM)  Vehicles  and 
Technologies.”  Report  submitted  to  the  Office  of  Naval  Intelligence.  Contact  author  at  SSC 
San  Diego. 
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Communication  in  the  VSW/SZ  will  be  very  difficult;  acoustics  are  extremely  noisy, 
and  RF  energy  is  absorbed  and  scattered  making  it  next  to  useless.  Deploy  antennas 
for  communications  and  navigation.  [Albus,  2001] 

Acoustics  hardly  ever  works,  especially  in  shallow  water.  [Yoerger,  2001] 

Communications  is  very  difficult  in  the  underwater  environment,  and  especially  in 
the  VSW/SZ.  Using  ultrasonic,  the  state  of  the  art  might  be  19.2  baud.  [Schempf, 
2001] 

Configure  your  project  to  succeed  even  without  acoustic  communications.  Give 
the  communications  group  a  firm  budget  and  have  backups  if  they  never  deliver. 

[Bradley,  2001] 

Multi-agent  collaboration  is  also  very  difficult  for  basically  the  reason  of  poor 
communications .  [Schempf,  2001] 

Communications  can  be  required  either  between  agents  or  between  an  agent  and  the 
human  operator.  Between  agents,  distances  may  be  quite  short,  and  information  requirements 
quite  small.  Just  the  opposite  may  exist  between  an  agent  and  the  human  operator.  One  well- 
understood  method  of  facilitating  short-range  communications  is  to  adjust  the  method  for  the 
medium.  As  the  agents  are  themselves  immersed  in  the  medium,  if  they  had  the  ability  to 
sense  the  transmission  characteristics  of  the  local  medium,  and  had  the  ability  to  adapt  their 
communication  methods,  then  between-agent  communications  may  be  possible  in  even  the 
most  severe  environments.  Communications  with  the  human  operator  are  still  disadvantaged 
by  distance  and  the  uncertainty  of  the  intervening  medium,  but  relays  of  communicating 
agents  may  reduce  these  problems.  DARPA  is  promoting  multiple  UGVs  to  establish  a 
flexible  RF  communications  network  [DARPA02], 

Computing  is  not  an  issue,  but  poor  communications  increase  computing  load. 

[Schempf,  2001] 

Un-tethered  systems  require  considerably  more  intelligence  than  tethered  versions 
designed  to  perform  similar  missions.  The  more  the  autonomous  capabilities  of  the 
system,  the  greater  the  range  independence  that  is  afforded.  [Walton  and  Uhrich, 
1995] 

The  iRobot  Swarm  control  processes  depend  upon  communications  among  the  agents.  IR 
links  are  currently  used,  however,  trails  are  also  under  consideration.  The  robustness  of  these 
methods  underwater  is  questionable,  but  an  acoustic  method  of  swarm  control  is  under 
development  at  iRobot  for  application  in  the  VSW/SZ  [iRobot], 

3.3.3  Other  Technology  Issues 

The  VSW/SZ  is  subject  to  strong  currents  and  water  turbulence;  vehicles  will  be  tossed 
about,  making  station  keeping  very  difficult.  The  power  available  to  small  UUVs  was  a 
concern  of  most  developers  we  interviewed.  Most  developers  indicated  that  navigation  was 
going  to  consume  lots  of  power,  while  several  recommended  strategies  to  conserve  power. 
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The  VSW/SZ  is  a  physically  turbulent  place.  Just  getting  around  will  be  difficult  and 
consume  lots  of  energy.  Disk  shape  facilitates  the  crab's  hydrodynamics  in  the  SZ, 
Consider  a  vehicle  the  shape  of  the  sand  dollar  with  water  jet  propulsion.  [Albus, 
2001] 

If  the  agent  "goes  with  the  flow"  then  it  needs  good  self-localization.  [Brooks,  2001] 

Much  of  the  power  in  UUVs  is  consumed  by  locomotion.  Currents  defeat  swimming 
vehicles,  obstacles  defeat  crawlers.  However,  a  more  successful  strategy  might 
combine  the  two.  [Schempf,  2001] 

If  one  agent  is  deployed,  it  must  have  very  good  acceleration  to  operate  in  the 
VSW/SZ.  [Brooks,  2001] 

The  amazing  ability  of  Salmon  to  negotiate  the  turbulence,  strong  currents,  and  obstacles 
of  down-rushing  streams  to  reach  spawning  grounds  must  be  admired,  if  not  emulated. 

Researchers  at  iRobot  have  tried  to  emulate  the  swimming  dynamics  of  fish: 

The  goal  of  the  DARTs  program  was  to  develop  a  series  of  small  autonomous 
underwater  vehicles  that  emulate  the  efficiency,  acceleration,  and  maneuverability  of 
a  fish.  These  biologically  inspired  robotic  craft  are  equipped  with  a  state  of  the  art 
system  of  flexible,  actuated  hulls  capable  of  producing  the  large  burst  of  force  needed 
for  fish-like  rapid  acceleration  and  turning.  The  prototype,  developed  in  cooperation 
with  MIT's  Department  of  Ocean  Engineering,  is  roughly  three  feet  long  and  consists 
of  a  series  of  lined  actuators,  a  spring-wound  exoskeleton,  flexible  lycra  skin,  and  a 
rigid  caudal  fin.  Modeled  after  a  pike,  its  foil  mechanism  "flaps"  to  create  vortices 
that  produce  jets  of  high  propulsive  efficiency.  [iRobot] 


Figure  4.  iRobot's  DARTs  fish-like  vehicle. 
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Track  drive  will  likely  be  more  useful  than  legs.  [Albus,  2001] 

Navigation  is  problematical  due  to  poor  sensing  and  communications,  and  due  to  the 
turbulence  of  the  environment.  GPS  could  work  if  one  could  deploy  an  antenna  above 
the  surface  of  the  water.  [Albus,  2001] 

Between  an  ROV  and  an  AUV,  the  AUV  is  a  niche  tool:  the  AUV  is  perhaps  more 
practical  to  operate  at  night;  the  AUV  is  more  energy  efficient  because  bright  lights 
are  not  needed  to  help  the  operator  navigate.  [Yoerger,  2001] 

For  an  underwater  application  (discounting  snorkeling),  the  UUV  will  be  limited  to 
battery  or  fuel  cells.  For  a  crawling  vehicle  to  be  able  to  withstand  turbulence,  it 
would  have  to  be  heavy,  thus  putting  a  larger  load  on  power.  The  UGV  community 
has  found  that  current  battery  capability  severely  limits  operational  life  and  they  are 
looking  to  fuel  cells  to  help  solve  the  problem.  In  many  cases  for  robots  under  100 
lbs,  the  mobility  and  navigation  power  requirements  limit  the  payload  capability.  If 
the  UUV  could  snorkel  and  use  a  system  with  higher  power  density,  that  would  help 
with  the  power  limitations.  [Clemons,  2001] 

In  some  scenarios,  it  might  be  possible  to  have  a  small  robotic  surface  platform  with  RF 
capabilities  running  a  fossil-fuel  generator,  and  providing  power  and  communications  to  a 
robotic  underwater  vehicle  to  which  it  is  coupled  via  an  umbilical  cable.  The  length  of  the 
umbilical  cable  may  be  minimized  by  coordinating  the  movements  of  the  surface  and  sub¬ 
surface  vehicles. 

Be  ruthless  about  your  hotel  load.  Make  every  effort  to  keep  it  a  small  fraction  of  the 
power  budget.  There's  no  excuse  for  a  system  where  the  computer  takes  30%  of  the 
system  power.  [Bradley,  2001] 

In  the  human,  and  we  presume  in  the  dolphin  as  well,  the  brain  consumes  approximately 
25%  of  the  body's  oxygen  (and  thus,  energy  metabolism)  at  rest.  Adaptive  processes, 
supported  by  this  considerable  computational  capability,  reduce  energy  requirements  overall. 

The  problem  of  energy  reserve  and  conservation  is  not  generally  a  significant  problem  for 
most  academic  developers  of  UGVs  who  either  dock  their  vehicles  at  recharging  stations  or 
simply  change  batteries  whenever  necessary.  Nature,  however,  has  appreciated  this  problem 
and  addressed  it  with  three  basic  approaches: 

■  First,  a  large  part  of  the  sensor,  motor,  and  central  controlling  apparatuses  of  each  and 
every  non-chlorophyll-containing  organism  is  dedicated  to  the  acquisition  and 
consumption  of  energy,  and  most  of  the  organism's  active  moments  are  so  directed. 

■  Second,  when  not  pursuing  energy,  most  organisms  sleep  or  go  into  suspended 
animation  to  conserve  energy. 

■  Finally,  when  external  energy  sources  are  in  short  supply,  the  organism  feeds  upon 
itself.  Stored  carbohydrates  are  burned,  followed  by  stored  and  structural  fat, 
followed  by  structural  proteins. 

The  top  priority  for  a  natural  organism  is  to  survive  by  acquiring  energy,  even  if  this  takes 
the  sacrifice  of  structural  elements  to  sustain  behavior  in  the  pursuit  of  more  energy. 
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Could  robotic  systems  be  similarly  designed?  If  an  energy-depleted  robot  is  useless,  then 
it  might  as  well  be  consumed  in  the  process  of  providing  energy  for  itself  so  that  it  can 
continue  to  perform  its  function  a  little  longer.  To  accomplish  this,  structural  elements  would 
have  to  be  convertible. 

Another  possibility  is  for  the  robot  agent  to  extract  energy  from  its  environment.  Breaking 
the  dependence  of  robots  upon  human  operators  for  energy  would  considerably  reduce  the 
amount  of  human  labor  that  is  currently  expended  in  support  of  the  robots.  It  may  be  also 
necessary  in  order  to  achieve  autonomously  adaptive  robot  operations  [Blackburn,  1984], 
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4.  RELEVANT  UGV  LESSONS  LEARNED 


An  excellent  starting  point  for  a  review  and  discussion  of  Lessons  Learned  from  the 
unmanned  ground  vehicle  work  is  a  recent  contribution  to  the  Army  Science  Board  (ASB) 
Summer  Study  for  2000  by  Jack  Taylor  (DUSD  [S&T])  on  the  status  and  challenges 
associated  with  technologies  critical  to  the  fielding  of  UGVs  [Taylor,  2001] .  These 
contributions  are  primarily  reproduced  in  the  Volume  on  Operations  of  that  study  [ASB, 
2000].  Of  particular  interest  are  the  several  informative  tables  and  associated  text  that  relate 
UGV  technologies  to  FCS  missions  and  to  expected  availability  schedules. 

In  its  Executive  Summary,  the  ASB  concluded: 

Robotic  technology  will  be  available  for  the  Army's  planned  development  for  either  a 

follower  or  an  assisted  path  robot  with  information  derived  from  the  organic  ISR 

system.  Autonomous  robots  were  judged  to  be  unavailable  for  2006  EMD  but  would 

be  available  for  2015-2025  insertions.  [ASB,  2000] 

An  earlier,  yet  still  relevant,  discussion  of  the  applicability  of  robotic  technology  to 
military  operations  (primarily  Army)  can  be  found  in  Robotics  Workshop  2020  [SAIC, 

1997],  The  Workshop  summary  presented  the  following  main  points: 

V  A  duality  was  noted  between  use  of  robotic  systems  for  tasks  that  humans  cannot 
or  should  not  execute,  and  use  to  enhance  human  actions. 

V  A  network  of  semi-autonomous  mobile  sensing  robots  of  varying  sizes  and 
attributes  was  seen  as  a  powerful  and  important  application. 

V  Automated  systems  can  play  an  increasing  role  in  information-related  tasks, 
including  the  more  "qualitative"  aspects  of  decision-making. 

V  Robotic  systems  as  decoys  were  a  favored  application. 

V  Of  the  various  sizes  of  robots  discussed,  "micro"  robots  were  seen  as  perhaps  the 
most  important  and  broadly  useful. 

V  Order-of-magnitude  advances  are  needed  in  artificial  intelligence  and  all  aspects 
of  mobility. 

V  Other  priority  robotics-related  R&D  pursuits  include  power  sources,  actuation, 
sensor  fusion,  and  materials. 

V  Prioritization  of  R&D  spending  for  robotics  should  consider  which  enabling 
technological  advances  must  be  pursued  by  DoD  and  which  might  be  adopted  or 
adapted  from  the  civilian/commercial  arena. 

V  New  operational  and  organizational  concepts  will  be  needed  to  gain  the 
maximum  utility  from  robotic  systems. 

V  Modularity  in  robotic  systems  was  seen  as  highly  desirable,  but  the  associated 
technological  difficulties  may  outweigh  the  advantages. 

V  There  was  a  strong  consensus  to  develop  classes  of  robotic  systems,  probably 
distinguished  by  gross  size. 

V  A  significant  degree  of  autonomy  will  be  the  key  to  robotic  systems  utility,  but 
autonomy  is  not  the  same  as  free  will. 

V  Participants  considered  the  feasibility  and  use  of  "telepresence"  as  alternative  to 
teleoperation. 
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■S  Development  of  "cyborgs"  might  be  an  innovative  way  to  achieve  covertness  in 
robotic  systems. 

■S  Biology  holds  a  number  of  potentially  important  inspirations  and  models  for 
robotic  development. 

Use  of  robotic  systems  by  the  military  may  have  important  implications  in 
deterrence. 

S  Appropriate  cultural  and  organizational  adaptation  must  be  considered  to  gain  the 
full  military  use  of  robotic  systems. 

■S  Robotic  systems  must  exhibit  military  behaviors,  but  they  need  not  necessarily 
exhibit  soldier  behaviors.  [SAIC,  1997] 

4.1  OPERATIONS 

We  will  now  review  Lessons  Learned  from  a  variety  of  other  individuals  involved  in 
unmanned  ground  robotics  programs,  as  program  managers  and  as  developers.  The  citations 
below  will  provide  justification  for  the  cautious  predictions  of  the  Army  Science  Board 
Summer  Study  for  2000  mentioned  above. 

4.1 .1  Lessons  Relevant  to  a  UUV  Operations  in  VSW  MCM  Missions 

4.1 .1 .1  Merits  of  Teleoperation 

In  the  teleoperated  vehicle  (TOV)  mode,  the  human  operator  supplies  all  of  the  necessary 
intelligence,  though  sometimes  depending  upon  sensory  data,  usually  video  imagery  and 
microphone  derived  audio,  transmitted  from  the  remotely  located  vehicle. 

An  in-service  teleoperated  vehicle  used  for  unexploded  ordnance  neutralization,  the 
RONS,  provides  some  insights  into  the  operational  and  technological  issues  of  teleoperation. 

The  Remote  Ordnance  Neutralization  System  (RONS)  is  strictly  teleoperated,  weighs 
600  pounds,  carries  a  five-degree-of-freedom  manipulator  arm  with  a  100-pound 
capacity.  Operators  drive  the  RONS  using  four  video  cameras,  by  either  RF  link  up  to 
1000  meters  or  by  fiber  optic  tether  up  to  750  meters.  The  vehicle  can  climb  stairs 
and  pass  through  a  standard  doorway.  The  human  operator  provides  all  of  the 
necessary  intelligence,  drives  and  navigates  the  vehicle,  detects  targets,  discriminates 
targets,  and  determines  the  placement  of  charges.  The  mission  is  to  clear  small  areas, 
generally  one  unexploded  ordnance  at  a  time.  Following  placement  of  a  charge,  the 
vehicle  is  driven  back  to  a  safe  place  and  the  charge  is  fired.  This  RONS  is  not 
suitable  for  large  mine  fields.  There  is  no  requirement  to  operate  covertly.  The 
vehicle  is  powered  by  lead-acid  batteries  which  can  be  recharged  by  the  operator's 
High  Mobility  Multipurpose  Wheeled  Vehicle  (HMMWV).  [Milcetic,  2001] 
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Figure  5.  Remotec's  RONS  teleoperated  vehicle. 

The  conditions  that  accompany  the  RONS  operation  limit  the  applicability  of  its  processes 
to  MCM  operations  in  the  very  shallow  water,  foremost  of  which  is  the  need  to  collect  and 
transfer  back  to  the  human  operator  adequate  sensor  information  for  navigation  and  task 
control.  Since  a  human  operator  must  drive  the  RONS  vehicle,  there  is  no  reduction  in 
human  labor,  although  the  human  operators  no  doubt  appreciate  the  stand-off  range  afforded. 

When  remotely  operating  the  Man  Portable  Robotic  System  (MPRS)  in  a  strict 
teleoperation  mode,  the  assessment  team  described  several  challenges,  including: 

V  limited  information  from  on-board  sensors; 

V  operator  fatigue; 

V  video  signal  degradation; 

V  and  poor  video  contrast  underground.  [Laird  et  al.,  2000] 

All  the  above  challenges  could  be  encountered  in  UUV  teleoperation,  along  with  a  few 
more  specific  to  the  underwater  environment.  However,  teleoperation  should  not  be  strictly 
dismissed  as  an  option  for  the  VSW  MCM  UUVs.  While  we  are  assured  that  RF  and  sonar 
communications  will  be  severely  limited  in  the  VSW/SZ  environment,  a  fiber-optic  link  from 
the  UUV  back  to  a  control  station  may  be  practical.  Such  fiber-optic  communications  for  a 
UUV  with  a  range  over  several  thousand  yards  was  demonstrated  at  the  Naval  Ocean 
Systems  Center  (now  SSC  San  Diego)  in  the  early  1980s.  The  major  difficulty  with 
teleoperation,  however,  remains  in  providing  adequate  sensor  information  for  the  human 
operator,  who  naturally  works  best  with  visual  input.  A  drawback  to  video  based 
teleoperation  for  underwater  uses  is  that  the  video  camera  requires  reflected  light  from  the 
subject,  and  while  low-wattage  chemical  lights  are  currently  used  by  divers  for  mine 
discrimination,  projected  light  from  a  UUV  is  undesirable  for  use  in  covert  night  operation 
and  for  its  power  consumption. 

A  teleoperated  vehicle,  and  any  ROV,  is  simply  an  extension  of  the  operator's  tool  set. 
Humans  learn  from  childhood  how  best  to  use  their  hands  and  sense  organs  to  operate  tools 
in  their  immediate  grasp.  Extending  those  tools  beyond  their  immediate  grasp  changes  all  the 
rules  that  they  have  mastered.  Many  children,  though,  already  come  trained  in  the  control  of 
ROVs,  at  least  those  that  have  had  the  opportunity  to  play  with  remotely  operated  or  radio- 
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controlled  cars,  boats,  and  airplanes.  The  control  functions  for  these  vehicles  are  generally 
easy  to  learn  as  long  as  the  child  can  view  the  motion  of  the  vehicle  in  response  to  control 
commands.  The  placement  of  cameras  on  the  moving  parts  of  the  ROVs  to  provide  more 
proximate  visual  information  to  the  remotely  located  human  operator  requires  the  learning  of 
new  transformations  that  are  not  common  to  radio-controlled  toys.  Not  surprisingly, 
operators  find  it  easier  to  learn  the  transformations  when  their  perspective  of  the  action  is 
taken  from  a  fixed  location  (as  they  have  when  operating  a  radio-controlled  toy). 

Retraining  the  operators  and  testing  their  competencies  with  new  tools  and  new  rules  for 
remote  manipulation  must  accompany  the  introduction  of  ROVs  into  the  operational 
environment. 

However,  for  an  alternative  opinion: 

Teleoperation  is  not  as  difficult  or  taxing  as  some  would  have  you  believe.  If  your 
designs  are  simple  and  effective,  the  learning  curves  are  short.  This  allows  operators 
to  qualify  quickly.  Anything  you  can  do  to  reduce  the  operator's  workload  is  good, 
and  highly  dense/complex  interfaces  do  more  harm  than  good.  [Klarer,  2001] 

4.1 .1 .2  Merits  of  Supervisory  Control 

The  many  difficulties  associated  with  teleoperation,  combined  with  the  current 
technological  unfeasibility  of  true  autonomous  robotic  control,  have  motivated  researchers  to 
try  a  hybrid  approach  to  control,  called  supervisory  control,  or  semiautonomous  operation.  In 
this  mode,  the  operator  provides  the  task  planning,  problem  solving,  and  perceptual 
discrimination  capabilities  to  the  system,  while  control  algorithms  running  on  the  robot 
provide  the  low-level  reactive  control  capabilities  useful  for  obstacle  avoidance  and  dead¬ 
reckoning  navigation. 

The  general  feeling  among  the  robotics  community  is  that  teleoperation  is  difficult 
because  of  the  manpower  and  communications  considerations.  At  the  same  time,  full 
autonomy  is  believed  to  be  too  hard  to  achieve.  Therefore,  any  control  scheme  will 
have  to  include  a  capability  to  notify  an  operator  when  the  robot  has  encountered 
difficulty  or  has  found  a  target.  Control  algorithms  will  probably  allow  one  operator 
to  control  a  number  of  robots  at  one  time  by  giving  high-level  orders  such  as  search 
area,  search  pattern,  way  points,  etc.,  and  let  the  robot  do  the  local  navigation  chores. 
[Clemons,  2001] 

Teleoperation  is  a  difficult  task  requiring  significant  training,  experience,  and 
practice.  Supervisory  control  can  often  support  similar  activities  but  require  less 
operator  expertise.  [Heath-Pastore,  2001] 

From  a  series  of  security  robot  prototypes  beginning  in  1980,  the  U.S.  Navy  provided 
technology  design  and  integration  for  the  development  of  the  Mobile  Detection  Assessment 
and  Response  System  Interior  (MDARS-I)  and  exterior  MDARS-E  platforms.  These 
platforms  were  designed  to  operate  semiautonomously,  following  predetermined  trajectories 
through  either  warehouses  or  supply  depots,  respectively,  avoiding  unexpected  obstacles,  and 
reporting  on  security  events  and  conditions  with  minimal  human  supervision.  The  MDARS-I 
platform  uses  sonar,  inertial  navigation,  and  the  recognition  of  specially  prepared  landmarks 
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to  maintain  its  trajectory  according  to  a  given  map  of  the  interior  spaces.  The  MDARS-E 
platform,  shown  on  the  right  in  Figure  6,  uses  primarily  differential  GPS  to  keep  itself  on 
track  while  following  its  surveillance  route  through  a  supply  depot. 


Figure  6.  GDRS  MDARS-I  and  MDARS-E  platforms. 

The  MDARS  team  at  SSC  San  Diego  expected  that  a  single  operator  could  control  a  group 
of  agents  dedicated  to  security  tasks.  This  expectation  led  to  the  development  of  the  Multiple 
Resource  Host  Architecture  (MRHA).  The  MRHA  permits  a  single  operator  to  command 
and  coordinate  several  robotic  platforms  that  are  used  in  physical  security  and  inventory  and 
barrier  assessment  inside  DoD  warehouses  and  outside  DoD  storage  sites.  The  automatic 
route  following  and  obstacle  avoidance  capabilities  of  the  employed  semiautonomous  robots 
permitted  this  more  efficient  use  of  human  labor. 

The  level  of  supervision  required  by  the  MDARS  platforms  is  minimized  by  the 
predictability  of  the  operational  environment.  When  conditions  are  more  uncertain,  more 
supervision  is  necessary  to  compensate  for  the  weak  perceptual  and  decision-making 
capabilities  of  the  platforms. 

Preliminary  user  evaluations  of  the  first  Man  Portable  Robotic  System  (MPRS) 
prototype  and  a  family  of  assorted  Operation  Control  Units  in  tunnel  exploration 
exercises  at  Ft  Leonard  Wood,  MO  have  shown,  however,  that,  under  the  conditions 
present  during  the  experiment/demonstration,  sophisticated  tele-reflexive  operation, 
even  with  a  simple  user  interface,  was  neither  required  nor  desired  by  the  operators. 
Operators  preferred  to  have  direct  and  absolute  control  over  the  operation  of  the 
vehicle.  [Laird  et  al.,  2000] 

The  MPRS  prototype  was  based  on  MDARS-E  control  technology.  The  amount  of 
supervision  required  to  ensure  the  safe  operation  of  the  vehicles  with  the  current  capabilities 
for  reflexive  (reactive)  control  in  complex  or  uncertain  environments  is  significant. 
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Figure  7.  Foster-Miller  platform  employed  as  the  MPRS. 


The  Demo  III  XUV  vehicles  also  evolved  from  the  MDARS-E  design,  and  were 
employed  in  a  RSTA  scenario  in  an  unstructured  operational  environment  (see  the  next 
section  for  more  on  the  operation  of  the  XUV). 

Even  in  a  supervised  autonomous  mode,  the  Demo  III  vehicle  commanders  were  over 
taxed  [Burns  et  al.,  2000]. 

The  determination  of  the  appropriateness  of  supervisory  control  may  depend,  however, 
upon  just  how  busy  the  operators  are  at  the  time: 

Soldiers  may  prefer  an  autonomous  system  when  under  fire,  but  a  teleoperated 
system  when  at  leisure  [Dodd,  2001] 

When  an  even  greater  degree  of  cooperation  is  required  among  the  robots,  the  re-addition 
of  human  operators  may  not  be  adequate.  Indeed,  the  human  operators  often  have 
coordination  problems  of  their  own. 

With  Fetch  II,  IS  Robotics  [a  division  of  iRobot]  has  built  a  test  bed  to  address  the 
questions  that  arise  when  multiple  munitions  clearing  robots  are  employed  to  sweep 
an  area.  How  can  a  lightly  trained  technician  operate  such  a  complex  system?  How 
can  the  robots  cooperate  with  one  another  to  perform  the  task  most  effectively?  The 
Fetch  II  robots  perform  their  tasks  autonomously  but  with  the  supervision  of  a  single 
operator.  Behavior  Based  intelligence  in  each  Fetch  II  enables  it  to  navigate  through 
real  world  terrain  autonomously,  using  a  relative  coordinate  positioning  system  and 
task-specific  sensors  mounted  on  a  robust  mobility  platform.  The  Behavior  Based 
software  mediates  robot-robot  interference  within  the  swarm  and  supports  mutual 
cooperation  among  them.  The  operator  is  free  to  task  the  robots  at  an  executive  level, 
using  a  graphical  map  interface  to  define  search  and  collection  areas  and  mark  likely 
or  unlikely  unexploded  ordnance  targets.  The  Fetch  II  supervisory  interface  supports 
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a  range  of  human-robot  interaction  styles,  from  high-level  re-planning  to  direct 
teleoperation  for  smooth  operation  under  various  contingencies.  [iRobot] 


Figure  8.  iRobot's  Fetch  II  vehicle 


The  plans  for  the  deployment  of  robots  in  space  face  the  problems  of  complex  and 
uncertain  environments  and  coordination  of  multiple  agents  assigned  to  the  same  task. 

But,  a  high  degree  of  supervision  over  robotic  operations  in  space  has  been  unfeasible  due 
to  the  delays  and  other  difficulties  in  communications. 

Presently,  sequences  of  commands  are  up-loaded  to  the  space  exploration  robots  for 
execution.  The  robot,  while  on  the  Moon,  Mars,  or  an  asteroid,  executes  the  command 
sequence,  if  possible,  and  then  waits  for  the  next  sequence.  Serious  exceptions  can  interrupt 
the  sequence. 

The  model  of  rover  operations  used  for  the  Mars-Pathfinder  rover,  Sojourner,  (and 
the  model  planned  for  the  Mars  ’03  twin  rovers),  is  to  manually  generate  sequences 
on  the  ground  and  when  necessary,  perform  additional  sequence  modifications  on  the 
ground  based  on  uploaded  data.  If  something  unexpected  happens  during  sequence 
execution,  such  as  an  out-of-range  sensor  reading  or  a  longer  than  expected  traversal, 
the  rover  must  be  “safed”  until  further  communication  from  the  ground  can  provide  a 
new  command  sequence.  This  procedure  often  causes  hours  of  lost  science  time  and 
makes  it  extremely  difficult  to  take  advantage  of  unexpected  science  opportunities. 
[Estlin,  et  al.,  2001] 

Clearly,  a  mechanism  local  to  the  robot  that  would  generate  mission-useful  sequences  of 
commands  that  would  maintain  robot  safe-state  parameters  and  deal  with  unexpected 
exceptions  to  the  task  environment  could  avoid  the  time-consuming  planning,  re-planning, 
transmitting,  and  reconfiguring  that  are  now  required  from  earth. 

There  is  much  in  common  between  the  underwater  and  space  environments.  Solutions  that 
are  effective  in  either  environment  should  be  seriously  studied  for  transfer  to  the  other. 
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4.1 .1.3  Lessons  Learned  from  the  Rationale  and  Results  for  Demo  III 


The  Demo  III  program  employed  the  experimental  unmanned  vehicle  (XUV),  which  was 
built  by  General  Dynamics  Robotics  Systems  (GDRS)  based  upon  the  MDARS-E  platform. 

Experience  with  the  MDARS-E  platform  permitted  the  rapid  development  and  testing 
of  the  Demo  III  XUV.  [Myers,  2001] 

Demo  III  addressed  three  major  areas  with  the  objective  to  solve  the  problem  of 
semiautonomous  navigation  through  a  complex  natural  terrain: 

■  Machine  perception 

■  Machine  intelligent  control 

■  Man-machine  interface  for  supervisory  control. 

The  issues  in  perception  derived  from  the  need  to  determine  the  most  appropriate 
path  for  traversal.  Examples  of  aspects  of  the  environment  that  had  to  be  detected 
were  foliage  type  and  density,  ground  slope,  ground  3-D,  and  ground  texture.  The 
most  difficult  machine  perception  problems  were  the  detection  of  below  ground 
obstacles,  and  the  characterization  of  foliage.  Active  millimeter  wave  sensors  have 
proven  useful  in  the  latter.  [Bornstein,  2001] 

The  issues  in  intelligent  control  derived  from  the  need  to  determine  the  most 
appropriate  military  (tactical)  behaviors.  Considerations  include  cover  and 
concealment,  potential  ambush  opportunities,  and  the  route  recon  requirements.  The 
implications  of  the  terrain  and  environment  must  be  factored  into  these  decisions. 
Terrain  navigation  algorithms  were  developed  upon  the  assumptions  that  cost 
functions  could  be  defined  as  essential  motivators.  Cost  factors  included  physics 
issues  and  tactical  issues.  Physics  issues  included  the  traversability  of  a  depression,  or 
of  foliage,  while  tactical  issues  might  be  the  opportunity  for  cover  and  concealment, 
making  a  depression  or  foliage  attractive.  The  development  and  testing  of  these 
decision  strategies  are  not  yet  complete.  [Bornstein,  2001] 


Figure  9.  GDRS  platform  (XUV)  employed  in  Demo  III. 
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The  issues  of  the  man-machine  interface  were  relevant  because  the  involvement  of  a 
human  in  the  operation  of  the  vehicle  was  always  required.  [Bornstein,  2001] 

The  most  significant  lesson  learned  was  that  "you  don't  know  what  you  don't  know". 
Thus  careful  experimentation  in  the  real  environment  is  necessary.  Modeling  and 
Simulation  (M&S)  is  useful  only  when  you  know  sufficiently  enough  either  about  the 
operational  environment  or  about  the  agent  that  must  operate  in  the  environment,  but 
if  there  is  much  uncertainty  about  both,  then  you  have  to  perform  the  tests  in  the  real 
world,  for  the  combined  uncertainty  defeats  the  utility  or  advantage  of  the  controls 
possible  with  M&S.  [Bornstein,  2001] 

The  Demo  III  program  took  the  approach  of  developing  a  sophisticated  on-board 
machine  intelligence,  following  the  inspiration  of  Jim  Albus  (NIST),  because  of  three 
factors:  doctrine,  economics,  and  control.  Doctrine  or  tactics  required  stealth.  Stealth 
would  be  lost  with  the  fielding  of  random  reactive  agents.  Economics  did  not  permit 
the  development  schedule  required  to  acquire,  test,  and  retrain  to  a  novel  military 
application.  Control  was  essential  because  of  the  anticipated  close  collaboration 
between  semiautonomous  machines  and  humans  in  the  operational  environment,  and 
could  not  be  guaranteed  with  random  reactive  machines.  [Bornstein,  2001] 

The  focus  on  the  RSTA  mission  was  designed  to  encourage  user  input.  The  objective 
of  the  Demo  III  program,  however,  was  not  to  develop  a  scout  vehicle  per  se,  but  to 
develop  semiautonomous  navigation  capability  in  a  natural  terrain.  Thus,  neither  was 
ATR  a  high  priority  investment  but  did  receive  attention  because  of  the  RSTA 
mission  scenario.  [Bornstein,  2001] 

Communications  were  addressed  using  available  military  equipment  at  the  brigade 
level.  The  limited  bandwidth  afforded  by  the  available  radios  required  attention  to 
greater  on-board  processing  capability.  [Bornstein,  2001] 

User  feedback  on  the  capabilities  of  the  Demo  III  XUV  has  been  extremely  informative, 
not  only  for  the  utility  of  the  state  of  the  implementation  of  the  technology,  but  also  on  the 
match  between  user  expectations  and  robot  functionality.  Following  is  a  sample  from  the 
Battle  Lab  Experimentation  Final  Report  (BLEFR)  for  the  Experimental  Unmanned  Vehicle 
(XUV)  Demonstration  III  ALPHA,  May  2000. 

In  this  experiment,  XUVs  operated  from  one  to  two  kilometers  in  advance  of  the 
manned  HMMWV  to  which  they  were  assigned.  The  user  interface,  the  Operational 
Control  Unit  (OCU),  is  a  stand-alone  computer  that  allowed  the  HMMWV 
commander  to  control  the  two  XUVs  assigned  to  him.  The  communication  system 
for  these  XUVs  was  the  Near  Term  Digital  Radio  (NTDR)  system.  [Burns  et  al., 
2000] 

The  Automatic  Target  Recognition  (ATR)  had  a  very  high  false-alarm  rate  and 
had  to  be  turned  off  to  prevent  inundating  the  operators  with  (false)  target  reports. 
Target  detection  was  limited  to  those  manually  panoramic  (near-real  time)  images 
by  the  OCU  operator.  [Burns  et  al.,  2000] 
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The  XUV’s  limited  obstacle  avoidance  ability  required  high  vigilance  and  close 
following  by  manned  safety  vehicles;  numerous  emergency  stops  (e-stops)  of  the 
XUVs  interrupted  the  natural  flow  and  development  of  scout  missions  and  the 
experiment.  [Burns  et  al.,  2000] 

Continually  evolving  diagnostic  procedures  resulted  from  different  vehicle  software 
configurations  and  hindered  the  collection  of  consistent  data  over  the  entire  trial  set. 

[Burns  et  al.,  2000] 

XUVs  were  assigned  36  route-reconnaissance  missions.  On  six  occasions,  the  XUVs 
failed  to  respond  to  the  mission  execution  message  sent  by  the  OCU.  These  six 
failures  are  attributed  to  failure  in  radio  communication  between  the  OCU  and  the 
XUVs,  not  to  the  OCU.  [Burns  et  al.,  2000] 

Conclusions  from  the  experiment: 

V  The  XUV  had  no  capability  to  avoid  negative  obstacles. 

V  The  XUVs  demonstrated  a  limited  capability  to  avoid  positive  obstacles.  The 
Demo  III  ALPHA  XUV  could  not  detect  enemy  vehicles.  [Burns  et  al.,  2000] 

General  Recommendations  from  experience  with  the  operational  control  unit  (OCU): 

V  Add  motion  video  as  opposed  to  still  imagery. 

V  Add  necessary  sensors  and  pass  information  to  the  OCU  to  let  the  OCU 
operator  know  the  location  of  robots  and  what  the  robots  are  viewing. 

V  Provide  default  RSTA  function  whenever  the  XUV  doesn’t  move  or  gets 
stuck. 

V  Provide  an  indicator  on  the  OCU  screen  of  the  XUV  inoperabililty. 

V  Provide  grid  lines  on  OCU  graphics. 

V  Provide  “Vehicle  Health  Status”  function  to  the  OCU  interface. 

V  Provide  depth  perception,  tilt,  and  slant  of  the  robots  to  the  operators.  [Burns 
et  al.,  2000] 

While  most  of  these  comments  appear  to  be  in  the  category  of  deficiencies,  and  do  not 
represent  the  successful  accomplishments  of  the  Demo  III  ALPHA  experiment,  problems  yet 
to  be  overcome  in  a  semiautonomous  (semiautomatic)  land  vehicle  are  certainly  obvious. 
Later  in  this  report,  we  will  introduce  comments  and  Lessons  Learned  from  the  technical  side 
of  this  particular  experiment.  (Demo  III  BRAVO  results  from  the  September  2000 
experiment  were  not  available  during  the  writing  of  the  present  report  in  April  2001. 

The  DARP A/Army  Demo  III  program  is  a  bold  attempt  to  provide  navigational  capability 
to  an  unmanned  vehicle.  The  MDARS-E  program,  using  similar  technologies,  is  one  of  the 
few  other  DoD  robotics  efforts  to  attempt  semiautonomous  (semiautomatic)  navigation.  At 
the  Force  Protection  Equipment  Demonstration  (FPED  III)  in  May  2001,  at  Quantico, 
Virginia,  the  MDARS-E  vehicle  was  the  only  UGV  present  and  operating  that  did  not  depend 
on  strict  remote  human  operator  control  for  operation.  Other  UGVs  at  the  demonstration 
included  those  manufactured  by  Foster-Miller,  I-Robot,  MESA  Associates,  and  Romotec. 
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These  last  robots  were  all  operated  by  remote  control  (TOV/ROV)  through  either  a  fiber¬ 
optic  or  radio  link.  Practical  examples  of  semiautonomous  vehicles  are  rare. 

4.1 .1.4  Merits  of  a  Complex  On-board  Intelligence 

Given  the  operational  difficulties  of  controlling  a  ROV  in  any  complex  environment,  we 
need  to  consider  the  alternatives.  Some  of  the  alternatives  that  UGV  developers  have 
suggested  include  the  addition  of  automatic  control  processes  that  may  preempt  operator 
actions,  or  kick-in  when  the  operator  fails  to  act  appropriately,  and  automatic  processes  that 
generally  control  the  UGV  unless  preempted  by  the  operator. 

These  alternatives  scale  to  the  degree  that  the  UGV  contains  sufficient  sensor  and 
computational  resources  to  make  navigation  and  task  decisions  independently  of  a  human 
operator.  To  make  independent  decisions,  whether  good  ones  or  bad  ones,  the  onboard 
intelligence  must  receive  information  that  would  ordinarily  be  available  to  the  human 
operator.  This  list  includes  state  information  on  the  vehicle,  a  variety  of  environmental  state 
information,  and  some  elements  from  the  tactical  picture.  In  addition,  the  vehicle  has  to  have 
the  means  by  which  to  act  appropriately  upon  that  information;  otherwise,  we  cannot  say  that 
a  decision  has  actually  been  made. 

What  type  of  intelligence  is  required  onboard  any  robotic  agent  to  integrate  the  available 
information  and  execute  some  appropriate  response? 

Different  approaches  to  robotics  control:  knowledge-based  vs.  behaviorist; 
deliberative  vs.  reactive  [Albus,  2001] 

Very  briefly,  we  will  try  to  contrast  these  approaches.  Knowledge-based  and  deliberative 
approaches  share  the  infusions  of  abstract  information  from  human  experiences,  which  are 
then  saved  in  searchable  data  structures.  As  the  robot's  circumstances  evolve,  the  control 
process  attempts  to  keep  up  by  recalling,  or  reconstructing  from  the  available  data,  a 
sequence  of  appropriate  responses.  The  knowledge-based/deliberative  approach  takes  its 
inspiration  from  the  cognitive  psychology  literature.  Expert  Systems  are  one  form  of 
knowledge-based  artificial  intelligence,  and  have  made  great  chess  players.  The  chess  game 
is  a  closed  environment,  and  the  rules  are  adhered  to  during  the  game,  making  it  possible  for 
optimal  or  near  optimal  plays  to  be  determined.  Expert  Systems  break  down  in  less 
constrained  environments. 

The  behaviorist  or  reactive  approach  encodes  somewhat  independent  low-level  responses 
to  specific  events  that  generalize  to  a  great  variety  of  circumstances.  The  robot  functions  by 
reacting  with  approach  or  avoidance  responses  to  classes  of  environmental  events  and 
stimuli.  The  most  well-know  proponent  of  the  behaviorist/reactive  approach  is  probably 
Rodney  Brooks  at  MIT.  The  behaviorist/reactive  approach  takes  its  inspiration  from  the 
neuroethology  literature.  Neuroethology  has  excelled  most  in  the  study  of  bugs,  fish,  and 
frogs,  species  that  do  not  appear  to  depend  much  upon  contemplation.  And  while  these 
species  survive  well  in  their  native  habitats,  rapid  changes  to  their  local  environments  can 
wipe  then  out.  We  should  expect  reactive  robots  to  be  similarly  vulnerable. 

Neither  the  knowledge-based  nor  the  behavior-based  approaches  adequately  represent  the 
biological  mechanisms  of  intelligence  from  which  they  derive  their  inspiration.  Some 
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essential  components  of  the  mechanisms  have  always  been  missing  from  both.  We  suggest 
that  the  critical  and  fundamental  elements  that  have  been  missed  are  those  that  define 
autonomy  in  the  biological  system,  whether  that  system  was  a  bug,  a  frog,  or  a  prince. 

The  limitations  of  architectures  of  automatic  processes  have  become  apparent  to  the  most 
notable  proponents  of  the  behaviorist  approach,  who  are  working  toward  remedies. 

IS  Robotics'  Self-Adaptive  Software  (SAFER)  project  was  developed  to  make 
existing  behavioral  control  systems  more  flexible  and  adaptive.  Current  systems  are 
not  efficiently  structured,  and  are  therefore  difficult  to  program,  forcing  software 
engineers  to  rewrite  the  same  functions  for  different  robots  and  debug  code  by  trial 
and  error.  . . .  Behavioral  control  is  a  decentralized  approach  to  the  architecture  of 
robotic  control  systems.  In  these  systems,  control  is  distributed  among  a  number  of 
asynchronous  behavior  modules  organized  in  a  subsumption  architecture,  in  which 
each  module  is  capable  of  operating  without  input  from  higher  layers.  . . .  Although 
these  systems  deliver  all  of  the  advantages  of  behavioral  control,  they  do  not  provide 
high-level  structure  or  system  feedback.  ...  By  adding  structure  to  multiple  behaviors, 
incorporating  performance  criterion  into  the  behaviors,  and  adding  facilities  to 
monitor  the  performance  of  behaviors,  IS  Robotics  will  establish  a  framework  for 
adapting  robot  behaviors  to  reflect  mission  goals  and  their  success.  [iRobot] 

A  greater  discussion  of  the  differences  between  the  knowledge-based  and  behaviorist 
approaches  goes  beyond  the  objectives  of  the  present  exposition,  but  the  lesson  is  that  each  of 
those  approaches  has  been  explored  with  varying  degrees  of  situational  success.  Neither  has 
proven  so  far  to  be  generally  applicable. 

A  second  question  deals  with  the  amount  of  intelligence  that  is  required. 

What  makes  more  sense  is  better  intelligence  in  a  few  UUVs:  Go  with  a  rich  world 
model.  Map  the  environment.  Carry  templates  of  the  expected  mine  types.  Planning  is 
easier  with  a  rich  model,  and  planning  must  be  continuous.  [Albus,  2001] 

Albus  is  indicating  that  even  if  the  state  information  is  provided,  all  of  the  equipment 
needed  to  operate  are  working,  and  the  computational  resources  are  adequate  to  the 
processing  load,  intelligent  results  cannot  be  expected  unless  the  decisions  made  are  based 
upon  prior  experiences.  By  extension,  the  greater  the  number  of  combinations  of  state 
variables  that  could  occur  and  that  could  be  germane,  and  the  greater  the  number  of  responses 
that  are  subject  to  success  or  failure,  the  larger  the  base  of  experience  that  must  be  available 
for  processing. 

While  there  is  no  universal  agreement  on  the  answers  to  the  questions  of  the  quality  and  of 
the  quantity  of  the  intelligence  required,  there  is  general  optimism  that  the  tools  needed  to 
answer  these  questions  are  improving  rapidly. 

Computing  power  continues  to  increase,  but  at  present  falls  far  short  of  even  the 
computational  power  of  a  rat  (—50  BIPS).  For  another  rough  estimate,  the 
computational  power  of  the  human  brain  is  100  TIPS  (100  trillion  instructions  per 
second).  [Moravec,  2000] 


38 


An  objective  of  the  VSW  MCM  UUV  program  is  to  reduce  the  need  for  human  divers  and 
marine  mammals  to  come  into  direct  contact  with  mines.  Humans  and  dolphins,  however,  are 
examples  of  the  most  intelligent  species  on  the  planet.  Due  to  the  difficult  operating 
conditions  of  the  mission,  considerable  onboard  intelligence  supporting  the  mission  functions 
may  be  required.  Dr.  Moravec's  analogy  may  provide  a  rough  estimate  of  the  feasibility  of 
this  objective.  Moravec  yet  continues  . . . 

The  incremental  growth  of  computer  power  suggests  an  incremental  approach  to 
developing  robot  intelligence,  probably  an  accelerated  parallel  to  the  evolution  of 
biological  intelligence  that's  its  model.  Unlike  other  approaches,  this  path  demands  no 
great  theories  or  insights  (helpful  though  they  can  be):  natural  intelligence  evolved  in 
small  steps  through  a  chain  of  viable  organisms,  artificial  intelligence  can  do  the 
same.  Nature  performed  evolutionary  experiments  at  an  approximately  steady  rate, 
even  when  evolved  traits  such  as  brain  complexity  grew  exponentially.  Similarly,  a 
steady  engineering  effort  should  be  able  to  support  exponentially  growing  robot 
complexity  (especially  as  ever  more  of  the  design  search  is  delegated  to  increasingly 
powerful  machines).  The  journey  will  be  much  easier  the  second  time  around:  we 
have  a  guide,  with  directions  and  distances,  in  the  history  of  vertebrate  nervous 
systems.  [Moravec,  2000] 

There  are  two  critical  factors  in  Moravec's  hypothesis.  First,  there  must  be  a  continuing 
orders-of-magnitude  increase  in  the  computing  power  available  for  our  artificial  intelligent 
systems.  Second,  there  must  be  an  increasing  viability  of  the  artificial  intelligent  systems  that 
we  produce  with  that  computing  power.  The  evidence  is  that  we  are  doing  pretty  well  on  the 
first  factor,  but  how  are  we  doing  on  the  second? 

Moravec's  choice  of  the  word  viability  is  quite  significant.  It  implies  survivability  or 
success  against  adversity.  We  must  ask  if  the  artificial  intelligent  systems  that  we  produce  are 
successful  in  this  way.  The  jury,  composed  of  all  field  tests  of  robotic  systems,  has 
demonstrated  that  they  cannot  survive  on  their  own.  They  must  be  guided,  supervised, 
protected,  and  nurtured.  We  have  no  autonomous  robots. 

We  should  consider  Moravec's  second  factor  carefully.  If  we  should  expect  that  viability 
will  improve  as  a  function  only  of  the  numbers  of  instructions  per  second  that  are  available  to 
the  computing  plant,  without  the  guiding  theories  or  insights  into  the  evolutionary 
mechanisms  of  intelligence,  then  we  must  be  prepared  to  suffer  many  evolutionary  dead 
ends.  A  predecessor  has  noted  that  a  pile  of  bricks,  no  matter  how  big,  will  not  constitute  a 
city.  Some  organizing  architecture  must  be  applied.  Do  we  now  have  the  right  architecture  in 
our  designs  of  UGVs?  Clearly  we  have  not  implemented  the  architecture  used  by  nature  in 
the  design  of  the  sensor  and  information-processing  components  of  the  human  and  dolphin  in 
any  of  the  major  UGV  systems.  We  have  not  even  implemented  the  architecture  used  by 
nature  in  the  design  of  a  cockroach,  for  the  cockroach  survives  even  under  our  very 
determined  efforts  to  eradicate  it. 

There  is  a  most  important  lesson  here.  If  humans  remain  in  the  information-processing 
loop,  or  if  humans  must  remain  in  the  system  operational  loop,  then  the  inadequacies  of  the 
artificial  intelligence  designs  will  be  masked  by  the  presence  and  capabilities  of  man  and  the 
evolution  of  even  more  complex  designs  will  be  based  on  a  "house  of  cards."  For  an  artificial 
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intelligent  system  to  be  viable,  it  must  work  unaided  by  man.  Indeed,  it  should  attempt  to 
survive  under  human  efforts  to  defeat  it. 

A  useful  approach  might  be  evolutionary  computing.  [Swinson,  2001] 

Thus,  we  should  start  small,  very  small,  and  restrain  our  ambitions  until  we  have  created  a 
device  that  can  get  along  in  a  very  limited  environment  without  us.  Next,  we  should  add 
capability,  not  to  satisfy  our  fancies  about  what  we  would  like  the  device  to  do,  but  rather  for 
the  device  to  meet  and  survive  one  new  challenge  in  its  environment.  Only  after  that  one  new 
challenge  has  been  successfully  met  should  we  introduce  a  new  challenge,  and  explore  the 
necessary  intelligent  mechanisms  to  survive  it  as  well.  This  process  is  evolutionary 
computing. 

For  robots  to  be  useful,  they  must  enjoy  survival-promoting  autonomy  and  sufficient 
intelligence  so  as  not  place  additional  burdens  upon  the  operators.  Some  of  the  requirements 
put  forth  by  users  and  developers  suggest  the  following: 

■S  A  vehicle  must  take  care  of  itself: 

■S  The  vehicle  must  auto  right  and  exhibit  other  auto  escape  and  recovery  modes. 

■S  The  vehicle  must  recharge  quickly. 

■S  The  vehicle  must  automatically  reacquire  lost  communications. 

■S  The  vehicle  must  discourage  abuse  and  curious  or  careless  handling. 

■S  The  vehicle  must  know  where  it  is  or  geo-localize  itself. 

■S  The  vehicle  must  negotiate  obstacles.  [Blitch,  2001] 

Homing  behavior  would  be  useful.  [Dodd,  2001] 

Even  the  above  list  contains  several  rather  sophisticated  and  advanced  capabilities  needed 
to  meet  rather  ordinary  tactical  challenges.  The  fundamental  objective  in  the  above  list, 
though,  is  that  the  operating  vehicle  must  reduce  the  workload  on  its  operators  or  human 
collaborators.  A  related  principle  involved  is  that  to  improve  the  probability  of  mission 
success,  the  vehicle  must  continue  to  operate  under  adverse  conditions  even  when  there  are 
no  human  operators  or  collaborators  around  to  assist.  We  should  not  expect  to  accomplish 
this  as  an  afterthought.  Instead,  it  must  be  fundamental  to  the  design. 

In  the  following,  Schwartz  agrees  with  the  assessment  of  the  problem,  but  has  a  different 
perspective  on  evolution. 

I  think  of  evolution  as,  first  and  foremost,  a  matter  of  growing  understanding  and 
experience  on  the  part  of  researchers  and  operators.  [Schwartz,  2001] 

Tactical  applications  of  unmanned  vehicles  in  unstructured  environments  are  tough 
and  the  technology  for  highly  autonomous  UGVs  (UUVs?)  is  not  here  yet.  Demo  III 
probably  represents  the  state  of  the  art  in  autonomous  UGV  mobility.  There  have 
been  a  number  of  false  starts  and  I'm  not  sure  they  are  at  an  end.  [Schwartz,  2001] 

Ideally,  one  would  like  an  evolutionary  path  that  leads  gradually  from  manned  to 
unmanned  operation,  but  I  usually  am  unsure  how  to  come  up  with  such  a  path. 
Evolution  should  mean  a  gradual  shift  in  the  division  of  labor  from  operator  to  robots. 
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This  requires  that  a  flexible  division  of  labor  be  built  into  the  design  that  allows 
adjustment  of  operating  procedures  based  on  experience  (as  well  as  on  immediate 
operating  conditions).  [Schwartz,  2001] 

Another  possible  example  of  evolution  would  be  to  try  to  overwhelm  the  problem 
with  sensors  and  processing  (damn  the  expense)  in  order  to  achieve  a  very  high  level 
of  performance.  Then  start  to  back  down  in  some  areas  (while  improving  in  other 
areas)  and  see  whether  this  can  be  done  so  that  performance  degrades  only  slightly, 
but  cost  declines  dramatically.  [Schwartz,  2001] 

Somewhat  related  to  the  last  thought  is  the  idea  that  "single  thread"  designs  are 
guaranteed  to  be  fragile.  A  competent  unmanned  system  to  perform  complex  tasks 
autonomously  is  going  to  require  a  design  that  embodies  fusion  of  multiple 
approaches.  [Schwartz,  2001] 

The  evolution  of  tactical  robotic  systems  must  involve  the  operators.  Thus  we  should 
start  with  a  manned  system,  and  add  a  coupled  robotic  component.  The  robotic 
component  must  permit  improvements  in  the  survivability  and/or  mission 
effectiveness  of  the  manned  system.  Doing  so  will  demonstrate  a  value  in  excess  of  a 
threshold  defined  by  cost  and  cultural  factors.  In  order  for  the  robotic  component  to 
permit  improvements  in  survivability  and/or  mission  effectiveness,  the  robot  must 
have  in  its  repertoire  a  number  of  behaviors  or  functions  with  which  the  operators  can 
experiment  as  they  adapt  their  tactical  operations.  The  operators  may  include  in  their 
experiments  varying  degrees  of  coupling  between  the  manned  and  unmanned 
elements.  In  this  way  the  operational  aspects  of  the  system  of  manned  and  unmanned 
elements  may  evolve.  This  process  says  nothing  about  how  to  supply  the  repertoire  of 
robot  behaviors,  but  it  does  offer  a  methodology  to  select  those  behaviors  that  are 
useful.  [Schwartz,  2001] 

We  are  returned  to  the  problem  of  developing  or  evolving  the  repertoire  of  robot 
behaviors. 

The  prevailing  concept  of  the  evolution  of  robot  technology  and  operational  capabilities 
from  TOV  to  AGV  is  reminiscent  of  the  ontogeny  of  man  from  infant,  to  child,  to  adolescent, 
to  mature  and  independent  adult,  in  that  in  human  development  a  shift  in  performance 
responsibility  gradually  occurs  from  the  parent  to  the  child  as  the  child  matures.  The  critical 
difference  here,  however,  between  a  human  infant  and  a  ROV  is  that  the  infant  already 
contains  all  the  elements  necessary  for  autonomous  behavior,  including  the  ability  to  ask  for 
help  when  help  is  needed.  The  product  is  essentially  complete  by  the  age  of  2  years,  even 
though  it  is  generally  useless  to  all  except  itself.  The  ROV,  on  the  other  hand,  has  none  of  the 
essential  elements  for  autonomy.  No  amount  of  experience  will  help  it  mature.  The  initial 
design  of  the  ROV  is  all  wrong  if  competent  autonomy  is  what  we  eventually  need. 

We  face  a  dilemma.  The  dilemma  is  that  we  need  to  incorporate  robots  into  our 
operational  environment  in  such  a  way  that  significant  realizable  benefits  result,  yet  we  can 
neither  afford  to  pursue,  nor  are  likely  to  achieve,  the  development  of  complex  behaviors 
without  first  establishing  a  foundation  of  rather  trivial  autonomous  processes. 
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4.1 .1.5  Why  it  is  Hard  to  Move  from  Teleoperation  to  Vehicle  Autonomy 

We  are  arguing  that  the  difficulty  in  providing  for  autonomous  capacity  in  robotics  is  in 
the  design  concept  for  the  vehicles.  That  concept  is  simply  that  the  system  must  meet  the 
needs  of  human  operators  and  auditors.  These  needs  so  strongly  influence  the  design  that  the 
operator  or  auditor  is  considered  a  virtual  passenger  of  the  robot.  For  example,  the  Demo  II 
vehicle  was  a  modified  HMMWV,  originally  designed  to  convey  and  protect  human 
passengers.  The  Demo  III  vehicle  is  an  extension  of  this  same  concept.  Principally,  it  is 
designed  not  to  roll  over  (humans  generally  do  not  like  to  roll  over),  and  to  convey  sensor 
packages  that  look  out  upon  the  world  for  the  benefit  of  human  observers  as  if  they  were 
riding  along  in  the  vehicle.  The  Demo  III  vehicle  concept  is  a  mobile  video  camera. 

The  current  wisdom  for  fielding  successful  robotic  systems  is  to  make  them  warfighter 
friendly,  or  to  put  it  differently,  to  make  the  system  architecture  warfighter-oriented. 

While  this  wisdom  is  relevant  to  the  degree  that  the  human  operator  will  be  involved  in 
the  control  of  the  UGV,  as  when  the  UGV  is  a  ROV,  or  participate  directly  in  the  task  with 
the  UGV,  it  may  impose  unnecessary  constraints  upon  the  UGV  design  and  operation. 

To  address  the  problem  stated  above,  however,  we  might  rephrase  the  wisdom  to:  Do  not 
build  an  architecture  around  the  concept  of  the  human  operator.  Make  the  architecture  task- 
oriented.  Then,  if  part  of  the  robot's  task  is  to  acquire  information  while  avoiding  bullets  and 
other  obstacles,  and  to  relay  that  information  back  to  a  human  subscriber,  the  robot's 
architecture  should  represent  design  priorities  that  are  directly  related  to  its  task  priorities.  It 
first  must  (1)  get  around,  (2)  survive  by  avoiding  obstacles  of  all  probable  types,  (3)  acquire 
information,  and  (4)  relay  that  information. 

The  UAV  designs  appear  to  satisfy  the  above  requirements  in  the  proper  order,  for  they 
fly  first,  avoiding  most  obstacles  (there  are,  after  all,  few  in  the  air),  and  acquire  and  transmit 
information  third  and  fourth.  The  small  tractor  drive  vehicle,  the  Foster-Miller  Lemming,  as 
used  by  MPRS,  also  approaches  this  design  philosophy.  The  Lemming  vehicle  has  a  very  low 
profile  (about  13  inches),  can  drive  right-side  up  or  up-side  down  for  as  long  as  its  batteries 
last  (about  3  hours).  If  provided  with  GPS -based  way-point  navigation  and  obstacle  escape 
algorithms  at  least  as  sophisticated  as  those  of  a  beetle,  the  Lemming  should  be  able  to 
traverse  unaided  a  few  thousand  yards  of  terrain,  making  a  net  forward  progress  at  about  1 
foot  per  second. 

It  is  hard  to  move  from  teleoperation  to  full  robot  autonomy  because  it  is  hard  to  develop 
the  perceptual  and  decision-making  abilities  of  man  in  a  computer  program,  and  because  we 
have  not  understood  how  to  develop  the  perceptual  and  decision  making  abilities  of  even  a 
cockroach,  and  because  the  autonomy  of  man  did  not  evolve  from  the  teleoperation  of  a 
cockroach,  but  rather  it  developed  from  the  autonomy  of  a  cockroach. 

If  we  do  not  require  the  robot  to  behave  (operate)  like  a  human  operator,  but  instead  find 
uses  for  the  behavioral  capacities  of  much  simpler  species,  then  the  achievement  of  autonomy 
at  that  level  might  be  a  little  easier. 

Humans  have  found  uses  for  simple  biological  systems.  For  example,  yeasts  are  added  to 
grains  and  fruits  to  transform  carbohydrates  into  alcohol  and  C02.  The  value  of  bee-keeping 
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has  long  been  recognized,  and  more  recently,  predatory  insects  are  released  into  orchards  to 
control  other  insect  pests.  Can  we  come  up  with  similar  useful  applications  in  the  context  of 
VSW/SZ  mine  countermeasures,  and  can  we  develop  even  the  simplest  forms  of  autonomy  in 
robotic  systems  to  address  those  applications? 

At  first,  we  must  be  satisfied  with  solving — providing  the  capabilities  for — very  simple 
tasks.  Then  we  may  add  little  by  little  to  the  task  difficulty,  achieving  solutions  at  each  point, 
all  the  while  evolving  the  computational  complexity.  At  some  point,  we  may  find  that  the 
solutions  no  longer  support  a  robustly  survivable  system.  It  would  be  appropriate  at  that  point 
to  end  further  development  of  that  architecture  and  try  some  other  promising  designs. 

We  have  been  using  the  term  semiautonomous  to  refer  to  a  system  that  contains  low-level 
automatic  functions  in  combination  with  teleoperation  for  direction  and  veto  control  by  an 
operator.  This  term,  semiautonomous ,  is  probably  a  misnomer,  as  there  can  be  no  autonomy 
in  combination  with  teleoperation,  and  because  the  low-level  automatic  functions  do  not 
define  an  autonomous  capability.  Automatic  functions,  often  implemented  in  behavioral  or 
reactive  processes,  require  useful  criteria  for  shaping  the  degree  and  direction  of  the 
responses  to  achieve  autonomy.  The  most  useful  criteria  from  the  point  of  view  of  the  agent 
is  the  preservation  of  energy  reserves  and  the  integrity  of  the  whole  (see  Section  4. 3.5.6  for 
definitions  of  autonomy  in  a  natural  as  well  as  an  artificial  context).  We  should,  for  accuracy, 
use  instead  the  term  semiautomatic. 

This  differentiation  of  automatic  from  autonomous  processes  is  not  intended  to  minimize 
the  importance  of  automatic  processes.  The  widespread  acceptance  of  the  automation 
provided  by  industrial  robots  has  adequately  proven  its  utility.  There  is  a  very  reasonable,  and 
now  demonstrable  expectation  that  similar  automatic  processes  can  be  implemented  in 
mobile  robots  that  are  properly  supervised.  There  is  then  a  navigable  path  between 
teleoperation  and  automatic  robots,  through  semiautomatic  designs,  but  this  path  will  not  take 
us  to  autonomy  if  that  is  our  objective;  and  we  will  surely  find  that  unaided  automatic  robots 
will  not  meet  our  operational  objectives. 

4.1 .1 .6  Tactical  Utility  of  Some  Elementary  Tasks 

At  this  point  in  our  commentary,  we  may  need  to  list,  as  examples,  some  elementary  tasks 
that  might  enable  autonomy  in  very  simple  agents.  We  should  also  assess  the  potential  of 
these  tasks  for  tactical  use. 

Example  #1 :  As  the  criterion  for  autonomy  is  survival,  and  the  transformation  of  energy  is 
evidence  of  survival,  an  autonomous  agent  should  be  able  to  manage  its  acquisition  and  use 
of  energy.  A  source  of  energy  that  is  generally  available  to  UGVs  during  the  daytime  is 
sunlight.  We  have  the  technology  to  capture  solar  energy  and  transform  it  to  electromotive 
power.  A  small  UGV,  if  provided  with  a  bank  of  photovoltaic  cells,  high-density  storage 
batteries,  some  actuators,  levers,  sensors,  and  control  algorithms,  could  spend  its  daylight 
hours  seeking  out  the  best  exposures  to  the  available  sunlight.  Jet  Propulsion  Laboratory’s 
(JPL)  Nanorover  is  an  appropriate  vehicle  for  this  application  [JPL],  The  vehicle  would 
require  sensors  for  its  energy  reserves,  charge  and  discharge  rates,  and  for  the  intensity  of 
sunlight  falling  on  its  photovoltaic  cells.  The  control  algorithm  would  have  to  decide  between 
energy  expenditure  involved  in  its  search  strategies,  and  passive  collection  of  solar  energy 
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under  the  given  circumstances.  The  tactical  utility  of  such  an  agent  could  depend  upon  the 
importance  of  having  an  agent  that  optimizes  the  recharging  of  its  batteries. 


Figure  10.  JPL  solar-powered  Nanorover. 

(Image  was  provide  through  the  courtesy  of  the  Jet  Propulsion  Laboratory 
California  Institute  of  Technology,  Pasadena,  California) 

Example  #2:  If  it  was  tactically  useful  to  distribute  agents  of  a  type  described  in  the  first 
example  over  a  large  territory  with  equal  separation,  then  the  agents  may  require  a  proximity 
sensor  that  gives  separation  information.  One  method  to  accomplish  this  is  to  have  each  agent 
broadcast  a  signal  that  is  offensive  to  all  other  agents.  That  is,  each  agent  attempts  to  move 
away  from  all  other  agents  whose  broadcast  signals  it  detects.  As  the  separation  distance 
increases,  the  strength  of  the  detected  signal  also  decreases  and  the  motivation  to  move  away 
from  the  signal  source  decreases.  Comparisons  of  signal  strength  from  different  directions 
may  permit  the  center  of  a  swarm  to  remain  in  place  while  the  peripheral  elements  expand  the 
area  of  occupation.  This  simple  mechanism  should  cause  all  agents  to  flee  from  all  other 
agents  and  to  maintain  a  fairly  uniform  standoff  distance  until  the  signal  strength  falls  below 
some  critical  threshold  for  motivation.  The  definition  of  uniform  would  be  based  upon  signal 
strength,  however,  rather  than  upon  physical  geographic  locations.  An  interesting  interaction 
of  this  control  algorithm  with  the  control  algorithm  of  Example  #1  could  permit  the  agents  to 
congregate  in  a  location  of  high  light  intensity  until  their  batteries  were  sufficiently  charged 
to  increase  their  broadcast  signal  strength.  Nonlinear  bifurcation  functions  for  these  control 
algorithms  could  prevent  fixations  at  equilibrium  points. 

Example  #3\  If  it  was  tactically  useful  to  have  the  distributed  agents  collect  local 
environmental  information  and  convey  that  information  back  to  a  human  auditor,  the 
broadcast  signal  of  Example  #2  could  be  used  as  a  carrier  of  local  information.  The 
distribution  algorithms  of  Example  #2  could  produce  a  network  of  agents  that  maintained 
themselves  just  within  hailing  distances  of  one  from  another  (including  the  human  auditor  if 
an  agent  was  physically  attached  to  the  auditor  at  the  edge  of  the  pack),  if  the  signal  strength 
requirement  for  communication  was  lower  than  the  signal  strength  threshold  for  separation. 
Ultra-wideband  (UWB)  radio  is  an  ideal  technology  for  this  application  because  it  consumes 
little  power,  and  the  timing  of  its  pulses  can  be  used  to  compute  relative  source  locations. 
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Example  #4\  If  it  was  tactically  useful  to  maintain  the  network  under  conditions  of  the 
periodic  loss  of  agents,  then  the  thresholds  for  separation  of  Example  #2  could  be  modulated 
by  the  number  of  UWB  radio  broadcasts  received.  As  agents  were  removed  from  the  network 
(either  through  battlefield  attrition  or  loss  of  power),  the  number  of  broadcasts  received  by 
other  agents  would  decrease,  and  the  separation  thresholds  could  be  increased,  bringing  them 
closer  together  and  thus  filling  in  the  gaps.  As  agents  came  back  online  following  their  auto¬ 
recharging,  the  network  could  once  again  expand. 

4.1 .1.7  Compatibility  with  the  Operational  Infrastructure 

Must  understand  the  operational  constraints.  The  new  technology  must  fit  in  with  the 
operational  infrastructure.  [Toscano,  2001] 

Conversely,  the  availability  of  teleoperated,  mixed-mode  (semiautomatic),  and  fully 
autonomous  robots  in  the  battlefield  will  likely  change  the  operational  environment. 

4.1.2  Lessons  Relevant  to  Target  Localization  and  Mapping  Techniques 

The  UGV  community  has  been  involved  in  mapping  techniques  from  their  inception.  The 
purpose  of  mapping,  however,  was  not  necessarily  to  locate  specific  targets  for  later 
acquisition  by  some  other  agent,  as  is  the  primary  objective  in  current  MCM  operations,  but 
rather  to  facilitate  the  navigation  of  the  UGV  through  the  environment  from  and  to  various 
locations.  The  map  was  used  to  plan  unobstructed  paths.  In  relatively  structured 
environments,  such  as  the  interiors  of  buildings  that  walls  and  doorways  define,  mapping 
errors  are  minimized  by  the  short  distances  from  the  identified  reference  points.  Short-range 
sonar  was  the  sensor  chosen  for  mapping. 

The  difficulties  with  the  addition  of  target  identification  and  mapping  to  the  data 
structures  developed  for  navigation  would  be  associated  primarily  with  perceptual  problems 
in  the  discrimination  of  the  targets.  As  sonar  did  not  contain  sufficient  information  for  target 
discrimination,  other  sensor  modalities  such  as  vision  and  barcode  and  RF  tag  reading  were 
used.  Only  vision,  though,  was  useful  for  non-cooperating  targets. 

Mapping  with  a  UGV  in  the  exterior  environment  posed  problems  more  similar  to  the 
underwater  environment.  Walls  and  doorways  were  too  few  and  far  apart  for  sonar  to  be  used 
to  map  them  and  to  provide  real-time  geographical  location  information  for  navigation.  The 
exterior  MDARS  robot  uses  primarily  differential  GPS  to  map  and  to  keep  its  position 
registered  when  negotiating  the  open  out-of-doors  spaces.  Of  course,  without  surface- 
penetrating  antennas,  GPS  would  not  benefit  an  underwater  vehicle. 

Another  simplification  generally  permitted  in  UGV  mapping  projects  is  that  the 
environment  is  two-dimensional.  That  is,  the  mapping  algorithm  assumes  that  any  object 
present  on  the  ground  plane  extends  vertically  into  the  third  dimension,  and  thus  represents 
an  impenetrable  obstacle,  but  the  vertical  dimension  is  otherwise  irrelevant,  as  the  vehicle 
neither  hops  nor  flies.  Since  the  vehicle's  motion  is  confined  to  two  dimensions,  such  a 
representation  of  the  environment  is  adequate.  This  simplification  may  or  may  not  be  useful 
in  the  VSW/SZ. 
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Generally,  the  UGV  mapping  approaches  required  stable  and  recognizable  reference 
points.  GPS  provided  reference  points  for  the  external  environment.  Rigid  walls  provided 
reference  points  for  the  interior  environment.  If  the  GPS  information  changed,  or  if  the  walls 
moved,  neither  could  have  permitted  accurate  mapping,  unless  the  changes  were  also 
understood  and  predictable. 

Most  academic  robotics  examples  today  are  too  constrained  to  be  applicable  in  the 
real  world.  [Thrun,  2001] 

The  academic  robotics  examples  are  also  in  many  cases  the  most  advanced.  What  about 
the  algorithms  must  be  changed  to  reduce  the  constraints?  If  the  academic  researchers  could 
answer  this  question,  would  they  have  already  done  so? 

4.1.3  Lessons  Relevant  to  Operational  Logistics  and  Supportability  Issues 

It  is  desirable  to  have  maintainability  at  the  user  level  [Milcetic,  2001]. 

Develop  a  system  with  as  many  line  replaceable  units  (LRUs)  as  possible.  The  more 
component  or  modules  that  you  can  allow  the  soldier/Marine  to  identify  problems 
with  and  replace  in  the  field  the  better  off  you  will  be.  Establish  a  well  defined,  easy 
to  follow  logistics  trail.  Simplify.  We  typically  use  contractor  logistics  support. 

[Anderson,  2001] 

Logistic  support  of  the  RON  is  provided  by  the  contractor,  who  maintains  the  depot 
and  delivers  supplies  to  the  field.  [Milcetic,  2001] 

The  viability  of  the  contractor  should  be  a  consideration  for  long-term  logistics  support. 
Several  robotics  efforts  in  academia  and  DoD  have  been  negatively  impacted  by  the  inability 
of  the  principal  supplier  to  continue  in  business,  while  the  small  product  market  precludes  the 
availability  of  alternative  suppliers. 

4.1 .4  Lessons  Relevant  to  Concepts  of  Deployment/Recovery 

Georgia  Tech  generally  deploys  and  recovers  robots  under  very  controlled 
circumstances,  so  there’s  not  much  to  offer  here  for  tactical  insights.  The  TMR 
program  has  advocated  “marsupial”  deployment  of  smaller  unmanned  systems  from 
larger  ones,  and  we  have  a  limited  capability  to  use  an  unmanned  Hummer  as  a 
delivery  vehicle.  Clearly,  there  is  some  applicability  of  this  technique  to  UUVs.  A 
swarm  of  small  UUVs  (maybe  SZ  MCM  crawlers)  may  be  completely  incapable  of 
reaching  a  destination  across  open  seas,  but  could  be  easily  delivered  by  a  larger  free- 
swimming  UUV  of  more  traditional  design.  [Collins,  2001] 

4.1 .5  Other  Operational 

There  is  a  need  for  a  Joint  Architecture.  There  is  too  much  isolation  between  the 
UGV,  UUV/USV  and  UAV  communities.  Strictly  from  a  UGV  standpoint,  the 
JAUGS  initiative  is  a  step  in  the  right  direction.  This  is  a  topic  which  was  discussed 
at  a  recent  seminar  hosted  by  the  Innovation  &  Transformation  Center  of  the  Joint 
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Experimentation  Directorate,  and  they  may  be  able  to  provide  some  of  the  briefing 
materials  that  came  out  of  our  discussions.  [Collins,  2001] 

See  Section  4.3.5. 1  for  more  on  JAUGS. 

Dr.  Steven  Metz’s  Strategic  Studies  Institute  paper  is  a  most  interesting,  if  not  highly 
speculative,  discussion  of  the  applications  of  robotics  in  military  operations  in  the  first 
quarter  of  the  21st  Century.  [Metz,  2000].  Unfortunately,  Dr.  Metz  provides  no  insights  into 
the  relative  merits  of  the  different  technological  approaches  that  might  be  taken  to  achieve 
the  required  capabilities  for  his  applications. 

4.2  PROGRAMMATICS 

4.2.1  Lessons  Relevant  to  Acquisition  Strategies 

Useful  to  have  "best-effort"  contracts  for  a  fixed  dollar  amount  (R&D).  [Toscano, 
2001] 

Make  sure  there  is  a  commercial  base  that  can  take  advantage  of  competition. 

[Toscano,  2001] 

Viable  commercial  applications  will  stimulate  robot  development.  [Moravec,  2000] 

The  Program  Office  may  fruitfully  cooperate  with  industries  or  other  agencies  that  have  a 
stake  in  the  exploitation  of  UUVs  in  VSW.  Examples  may  be  fishing,  and  environmental 
preservation  or  restoration  (e.g.,  following  oil  spills). 

One  essential  question  of  the  acquisition  strategy  (for  the  Remote  Ordinance  Neutraliza¬ 
tion  System  [RONS],  see  Section  4. 1.1.1)  appears  to  concern  the  degree  of  control  over  the 
developmental  process  that  should  be  maintained  by  the  Program  Office,  versus  the  degree  of 
control  that  should  be  turned  over  to  a  Prime  or  Integration  Contractor.  Overall  costs  to 
delivery  could  be  lower  in  the  latter  case,  but  in  an  area  where  either  the  technology  base  or 
the  operational  doctrine  are  rapidly  changing,  the  former  might  be  more  appropriate. 

The  acquisition  strategy  included  R&D  and  production  phases  to  the  same  contractor. 
This  permitted  rapid  transition  to  MS  III  productions  and  early  fielding  of  the 
product.  This  was  made  possible  by  an  existing  commercial  capability  that  nearly  met 
the  military  requirements.  The  difficulty  with  the  strategy  became  apparent  when 
product  improvements  were  required.  A  new  contract  had  to  be  written  to  perform 
Planned  Product  Improvements  (PPI).  New  requirements  are  managed  by  an  IPT  that 
negotiates  risks  for  technology,  schedule,  and  cost.  A  possible  solution  to  the 
dilemma  of  anticipating  PPIs  when  the  details  are  unknown,  and  yet  using  the 
original  R&D  &  production  contract,  might  be  to  write  R&D  delivery  orders. 
[Milcetic,  2001] 

The  High  Altitude  Endurance  Unmanned  Aerial  Vehicle  Program  required 
unanticipated  software  development  and  unexpectedly  complex  integration  tasks 
causing  schedule  slips  and  cutbacks  in  scope.  The  contractor,  while  relieved  of 
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traditional  government  oversight,  did  not  develop  and  implement  necessary 
management  controls  of  its  own.  [Drezner  et  al.,  1999] 

All  programs  that  attempt  to  provide  for  useful  semiautomatic  or  autonomous  behavior  in 
an  unmanned  system  will  face  these  complexity  issues.  An  acquisition  strategy  that  provides 
too  much  autonomy  to  the  contractor,  no  matter  how  experienced  or  competent,  risks 
unpleasant  surprises  as  a  consequence  of  the  contractor's  struggles  with  the  unexpected. 

4.2.2  Lessons  Relevant  to  Test  and  Evaluation 

When  developing  performance  specifications,  be  clear  and  concise  on  the 
performance  requirements  without  telling  the  contractor  how  to  build  the  system. 
Keep  the  number  of  people  on  your  integrated  process  team  that  is  developing 
performance  specifications  to  the  lowest  number  possible.  Too  many  will  just  clog 
up  the  process.  Filter  the  performance  specifications  through  the  requirements 
developer  to  make  sure  that  your  interpretation  of  the  performance  and  theirs  is  the 
same.  [Anderson,  2001] 

Affordability  must  be  a  key  performance  parameter.  [Toscano,  2001] 

How  to  identify  Key  Performance  Parameters?  Create  a  list,  vote  on  importance, 
assign  weights,  take  the  top  few  on  the  list.  Make  sure  that  they  are  testable. 
Examples:  minimal  time  on  target,  portability,  survivability  given  specific  threats. 

[Milcetic,  2001] 

The  man-machine  interface  must  be  tested  in  a  high-stress  condition.  [Dodd,  2001] 

It  is  difficult  to  quantify  the  performance  of  a  real  robot  in  a  mission  of  any 
significant  complexity.  There  are  too  many  parameters  to  vary  to  allow  any 
systematic  investigation  of  the  possibilities,  especially  since  actual  runs  can  take  a 
while.  It  is  reasonable,  though,  to  task  human  test  subjects  with  robot  missions  and 
allow  them  to  “specify”  (essentially  to  construct  the  robot  program)  and  test  these 
missions  in  simulation.  That  is  the  typical  nature  of  our  usability  studies  mentioned 
earlier.  In  such  studies,  the  performance  parameters  are  mission  success,  time  to 
specify  (construct)  mission,  number  of  mouse-clicks,  number  of  “do-overs”, 
debriefing  comments,  etc.  [Collins,  2001] 

4.2.3  Lessons  Relevant  to  System  Definition 

Requirements  might  be  divided  up  among  several  system  solutions,  each  taking  on  a 
piece  of  the  problem.  [Toscano,  2001] 

There  is  a  tendency  to  focus  on  technology  that  enhances  the  performance  of  the 
unmanned  vehicle(s)  as  opposed  to  focusing  on  enhancing  the  performance  of  the 
system  that  includes  not  only  the  unmanned  vehicles  but  also  the  human  operators 
and  the  communication.  The  division  of  labor  between  the  robots  and  the  operators 
and  maximizing  the  span  of  control  of  the  operators  are  critical  issues.  To  the 
maximum  feasible  extent,  robots  should  be  able  to  ask  for  help  from  the  operator. 
[Schwartz,  2001] 
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Don’t  go  for  the  "Swiss  Army  Knife"  solution.  One  robot  need  not  do  it  all.  Several 
more  specialized  but  cheaper  robots  might  serve  as  well,  if  not  better.  Deploy  the 
specialized  solutions  as  intelligence  and  the  situation  dictate.  [Schempf,  2001] 

Sensing  will  also  be  very  difficult.  Low-frequency  acoustics  may  work  with  multiple 
vehicles  creating  a  sensor  array,  but  this  demands  good  communications,  which  are 
unlikely.  [Albus,  2001] 

Modular  designs  permit  upgradability  by  parts.  [Heath-Pastore,  2001] 

We  [at  SANDIA]  have  had  success  making  our  software  and  hardware  somewhat 
modular,  and  have  managed  to  'standardize'  on  a  few  configurations  but  in  some  ways 
that  limits  what  you  can  accomplish.  [Klarer,  2001] 


Figure  1 1 .  SANDIA  Hagar  vehicle  using  modular  technology. 

4.2.4  Lessons  Relevant  to  Other  Programmatic  Issues 
4.2.4.1  Lessons  Learned  from  Early  Navy  Robotics  Programs 

Bart  Everett,  in  a  1985  Naval  Sea  Systems  Command  (NAVSEA)  technical  report, 
identified  causes  for  difficulties  in  many  early  Navy  robotics  programs: 

■S  Poor  communication  and  feedback  between  all  concerned  parties,  particularly 
with  users. 

S  Inadequate  understanding  of  required  operational  capabilities,  coupled  with  a  lack 
of  appreciation  for  the  technology  deficiencies. 

•S  No  workable  long-term  robotics  plan. 

•S  No  baseline  assessment  of  technology  capabilities  and  deficiencies. 

■S  Failure  by  project  managers  in  the  initial  planning  stages  to  possess  a  working 
knowledge  of  the  technology  and  actively  use  the  [available]  resources. 
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•S  Inadequate  6.1  and  6.2  efforts  prior  to  initiating  6.3  level  development. 

■S  Failure  to  meet  design  goals  due  to  the  existence  of  technology  voids  unidentified 
early  in  the  process.  [Everett,  1985] 

Elaborating  upon  the  above  list,  Everett  continued: 

The  challenge  is  to  keep  existing  projects  from  overreaching,  while  building  up  a  well 
developed  robotic  technology  baseline.  Timely  and  appropriate  steps  must  be  taken  to 
ensure  that  available  robotic  technology  is  employed  . . .  [Everett,  1985] 

...the  measure  of  effectiveness  for  specific  applications  must  be  determined. 
Development  and  use  of  appropriate  cost  models,  understanding  of  system  needs,  and 
the  requirement  for  compatibility  and  standardization  are  all  important... [Everett, 
1985] 

...program  activity  [must  be  extended]  into  such  areas  as  intermediate  and  depot  level 
repair  [to  control  life  cycle  costs].  [Everett,  1985] 

Additional  concerns  include  the  impact  on  training,  manning  levels,  operational  concept 
validation,  and  mission  readiness. 

4.2.4.2  Lessons  Motivating  the  MDARS  Program 

Everett,  in  a  later  look  at  the  historical  short-comings  of  some  predecessor  projects, 
produced  the  following  list  as  part  of  a  report  on  the  acquisition  strategy  for  the  Mobile 
Detection,  Assessment,  and  Response  System  (MDARS)  project. 

■S  Lack  of  a  bona  fide  application  and  validated  payback. 

■S  Ignorance  on  the  part  of  the  project  manager  and/or  developing  organization 
as  to  what  the  user  really  wanted. 

■S  Lack  of  awareness  in  the  minds  of  the  user  as  to  what  the  near-term 
technology  could  and  could  not  support. 

■S  Overlooked  or  under-estimated  systems  integration  efforts. 

•S  Constantly  changing  goals  and  objectives,  sometimes  as  a  result  of  turnover  at 
the  program  office. 

S  Insufficient  funding  and/or  requirements  creep. 

■S  Premature  attempts  to  apply  off-the-shelf  components  without  fully 
understanding  the  system  needs. 

■S  “System  shock”  arising  from  too  abrupt  a  transition  from  the  ideal  laboratory 
environment  to  the  harsh  realities  of  real-world  applications. 

S  Insufficient  documentation  to  support  program  transitions  from  R&D  phases  to 
production.  [Everett  et  al.,  1996]3 


3  H.  R.  Everett,  R.  T.  Laird,  T.  A.  Heath-Pastore,  G.  A.  Gilbreath,  and  R.  S.  Inderieden. 
1996.  “Technical  Development  Strategy  for  the  Mobile  Detection  Assessment  Response 
System-Interior  (MDARS-I).  Technical  Note  1776  (Aug).  Contact  authors  at  SSC  San  Diego. 
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A  discussion  upon  these  Lessons  Learned  from  the  same  MDARS  publication  is  of 
sufficient  value  to  quote  nearly  in  total  here. 

■f  Program  managers  did  not  appreciate  the  issues  associated  with  a  software¬ 
intensive  program.  —  Most  treated  software  as  if  it  were  magic,  and  expected 
unrealistic  end  results  without  understanding  anything  about  the  process. 

There  was  little  (if  any)  appreciation  of  the  costs  associated  with  development, 
much  less  maintenance.  This  deficiency  resulted  in  a  lot  of  spaghetti  code  that 
could  not  be  maintained,  much  less  upgraded. 

•S  The  projects  displaying  the  greatest  likelihood  of  success  were  relatively  small 
and  very  focused  in  terms  of  their  stated  objectives.  —  With  limited  resources 
and  experience,  it  is  very  prudent  to  focus  on  an  achievable  objective  without 
trying  to  solve  all  the  problems  of  the  world. 

•S  The  bigger  the  performing  organization,  the  lower  the  chances  of  success.  — 
This  was  especially  true  in  the  case  of  large  corporations  with  high-powered 
sales  and  public  relations  capabilities  that  had  been  displaced  from  other 
business  pursuits  (i.e.,  petroleum  industry,  nuclear  industry,  space  program) 
and  had  no  real  robotics  experience. 

•S  The  greater  the  number  of  active  players  and  organizations,  the  less 

likelihood  of  meaningful  developmental  results.  —  Problems  associated  with 
the  effective  coordination  of  a  large  group  of  geographically  dispersed 
organizations  soon  overshadows  any  perceived  synergism.  There  are  much 
more  effective  ways  to  achieve  the  same  desired  results  through  technology 
transfer. 

Continuing  on,  Everett  et  al.  wrote: 

With  regard  to  this  last  point,  there  is  a  strong  natural  tendency  when  managing  a 
high-risk  new-technology  effort  to  feel  that  having  more  players  on  the  team 
translates  to  more  bases  covered,  with  less  likelihood  of  something  falling  through 
the  crack.  Experience  has  repeatedly  shown,  however,  that  beyond  a  certain 
optimal  point  the  reverse  is  actually  true.  It  is  highly  desirable  to  have  a  broad 
mix  of  backgrounds  and  talents,  but  it  takes  a  skilled  and  experienced  manager  to 
recognize  the  point  of  diminishing  returns.  The  ideal  developmental  approach 
provides  an  optimal  mix  of  both  government  and  industry.  Given  the  limited  (and 
shrinking!)  number  of  adequately  trained  government  employees  in  the  field,  this 
situation  is  understandably  sometimes  difficult  to  achieve. 

Nearly  all  of  the  [previous  DoD]  programs  were  successful  in  demonstrating 
technical  feasibility,  but  only  a  very  small  percentage  were  able  to  demonstrate 
value  added. 

It  should  therefore  be  rather  obvious  that  MDARS  is  not  going  to  be  the  first  to 
succeed  where  so  many  others  have  failed  by  cutting  corners  and  eliminating 
necessary  work.  Such  an  approach  introduces  significant  potential  for 
catastrophic  failure  in  a  highly  visible  program.  On  the  positive  side,  however,  a 
number  of  very  effective  strategies  have  been  employed  by  astute  managers  with 
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limited  budgets  in  order  to  minimize  the  technical  risk  and  increase  the  chances  of 
programmatic  success: 

■C  Identify  common  technological  needs  and  address  jointly.  —  While  this 
sounds  good  on  paper,  the  recurring  problem  in  practice  has  been  the 
repeatedly  demonstrated  unwillingness  of  different  government  organizations 
to  work  together  towards  a  common  goal. 

Minimize  the  pressure  to  let  “politics”  override  sound  technical  judgment.  — 
This  all  too  common  practice  has  killed  more  well-intentioned  attempts  than 
probably  any  other  single  cause. 

■C  Avoid  any  tendency  to  adopt  a  “not-invented  here”  attitude.  —  The  first 

successful  robotic  fielding,  when  it  comes,  will  ride  the  coat-tails  of  a  number 
of  previous  attempts,  taking  full  advantage  of  all  the  lessons  learned.  Look 
the  other  way  and  you  become  a  lesson  for  someone  else. 

■f  Be  willing  to  eat  your  young.  —  The  technical  development  team  must  be 
constantly  on  the  lookout  for  newly  introduced  capabilities,  and  not  hesitate  to 
abandon  an  in-house  approach  if  better  options  come  along  from  alternative 
sources."  [Everett  et  al.,  1996] 

4.2.4.3  How  to  Come  up  with  Better  Solutions 

Start  with  the  end  objective  in  mind,  then  work  backward.  Avoid  up-front 
assumptions,  i.e.  an  integrated  robot,  or  a  biological  approach  (neither  man-like  nor 
crab-like).  [Schempf,  2001] 

Schempf  s  warning  to  avoid  up-front  assumptions  is  wise,  but  keeping  any  particular 
objective  in  mind  could  defeat  that  caution.  Take,  for  example,  that  we  want  to  visit  our  Aunt 
Thelma  who  lives  in  Minneapolis.  In  planning  our  trip,  we  may  be  tempted  to  state  that  our 
objective  is  Minneapolis,  for  it  is  a  definite  location  on  the  map  that  we  know  how  to  find. 

But  this  could  give  us  problems,  particularly  if  Aunt  Thelma  just  happened  to  be  vacationing 
in  Hawaii  at  the  time.  Rather,  we  should  have  understood  that  our  objective  was  to  visit  Aunt 
Thelma,  provided  that  she  was  accessible. 

We  use  the  term  Mine  Countermeasures  (MCM),  not  fully  aware  that  this  term  is  loaded 
with  bias  that  may  send  us  where  we  do  not  need  to  go  to  reach  our  objective.  The  biases 
associated  with  MCM  are  that  mines,  dangerous  ones  at  that,  are  going  to  be  in  place  and 
must  be  countered.  We  could  counter  them  by  finding  them,  and  then  by  going  around  them, 
or  by  destroying  them  in  place.  But,  there  are  other  approaches  that  could  be  taken. 

One  approach  could  be  that  we  might  discourage  the  initial  placement  of  mines.  (We 
mentioned  this  possibility  first  in  Section  3.1.1.)  One  way  to  state  our  objective  that  might 
eliminate  most  of  the  inherent  biases  would  be  no  mines.  A  similar  medical  model  of  this 
approach  is  the  prevention  of  infections  through  inoculations.  Inoculations  prepare  the  natural 
body  defenses  to  eliminate  the  pathogen  upon  its  subsequent  introduction.  Innoculations  save 
a  great  deal  of  effort  later  in  terms  of  countermeasures  to  infections. 

When  defining  your  program,  write  the  concept  of  operations  (CONOPS)  first  and 
then  invite  industry  in  to  comment.  [Dodd,  2001] 
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While  industry  is  pragmatic,  it  is  also  profit-oriented.  The  concept  of  operations,  if 
defined  first,  could  drive  the  search  for  a  cost-effective  solution.  Otherwise,  the  profit- 
effective  solution  could  drive  the  operational  concepts  and  associated  requirements. 

A  concept  of  operations  should  consider  both  day  and  night  conditions,  and  different 
water/bottom  conditions.  [Landry,  2001] 

Ensure  that  program  managers  wait  until  their  operational  requirements  document 
(ORD)  is  complete  and  approved  before  beginning  to  develop  a  final  system.  Much 
energy  and  resources  could  be  wasted  by  a  PM  trying  to  jump  ahead  of  events 
without  an  approved  ORD.  [Adams,  2001] 

Keep  the  user  involved  at  all  times  when  decisions  must  be  made  on  design, 
limitations  of  the  system,  immaturity  of  technology  that  affects  the  system, 
appearance  and  maintenance  support.  Sometimes  the  user  will  have  a  difficult  time 
understanding  limitations  due  to  technology,  cost  or  schedule.  There  may  come  a 
time  when  you  need  to  call  in  an  objective  third  party  to  hear  both  sides  of  an  issue  to 
get  a  different  perspective.  This  third  party  must  be  neutral  and  an  expert  in  the  area 
of  concern.  This  outside  voice  may  offer  insight  or  experience  that  will  be  useful  to 
both  sides.  However,  at  the  end  of  the  day,  the  user  must  be  satisfied  with  the  system 
and  understand  why  he  made  a  tradeoff.  [Folk,  2001] 

4.2A.4  Value  and  Risks  of  Demonstrations 

Early  user  involvement  is  important,  but  be  aware  that  expectations  may  exceed 
system  capabilities  in  early  demonstrations.  [Landry,  2001] 

The  biggest  problem  encountered  in  the  MPRS  prototype  demonstration  was 
inadequately  trained  operators,  who  have  little  or  no  troubleshooting  experience  with 
the  unique  system.  [Bruch  et  al.,  2000] 

Expect  a  large  amount  of  the  available  resources  to  go  into  debugging,  and  demo 
preparation.  [Gage,  1999] 

But,  this  may  be  true  only  because  too  few  resources  were  put  into  development  of  a 
brilliant  universal  overarching  architectural  scheme  and  its  testing  under  all  realistic 
operational  conditions. 

The  success  of  a  demonstration  is  often  state-dependent,  that  is,  dependent  upon  the  state 
of  the  developer/demonstrator.  Adequate  attention  to  coordination,  team  management,  and 
training  are  essential. 

During  demonstrations,  the  urge  is  to  attempt  too  much,  which  increases  the  likelihood  of 
failure  in  a  complex  and  inadequately  tested  system.  When  the  purpose  of  a  demonstration  is 
to  show  successful  capabilities,  ambitious  objectives  must  be  restrained. 

In  operational  testing,  plan  for  bad  weather.  [Gothard  et  ah,  2001] 
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One  serious  problem  with  the  Demo  III  design  or  developmental  process  was  that  one 
problem  was  attacked  at  a  time.  There  was  no  general  solution.  Some  problems  did 
not  receive  consideration  until  they  appeared  unexpectedly  in  the  environment. 

[Haug,  2001] 

This  systematic  approach  to  problem  solving  would  ordinarily  be  applauded  if  the  subject 
system  was  simple  or  if  the  number  of  determining  factors  in  the  outcome  of  any  trial  were 
few.  But  the  natural  environment  is  quite  complex,  and  the  requisite  number  of  component 
parts  that  participate  in  any  one  operation  are  considerable.  One  fundamental  problem  with 
the  DARP A/Army  Demo  series  is  the  extremely  ambitious  objective  to  assemble  an  artificial 
system  that  demonstrates  pretty  sophisticated  human-like  abilities.  What  makes  the  objective 
extremely  ambitious  is  that  it  was  attempted  without  first  having  been  able  to  demonstrate  the 
integrated  repertoires  of  any  number  of  less  capable  species  that  none-the-less  traverse 
difficult  terrain,  avoid  obstacles,  acquire  and  pursue  targets,  and  defend  themselves. 

4.2.4.5  Value  of  Prototyping 

Close  the  loop  with  users  throughout  the  design  and  development  process.  Implement 
phased  rapid  prototyping  and  provide  prototypes  periodically  to  the  users  for 
evaluation.  Build  a  strong  relationship  with  the  user,  educate  the  user  on  relevant 
technologies,  and  become  educated  on  the  user's  mission  and  requirements.  Use  this 
relationship  to  make  good  financial  and  technical  tradeoff  decisions.  [Everett  et  al., 
19964;  Heath-Pastore,  2001;  Knichel,  2001] 

This  has  been  especially  helpful  in  defining  paragraph  4a  of  the  Operational 
Requirement  Document5.  [Adams,  2001] 

DARPA  has  been  a  good  source  for  vehicles  for  this  purpose.  [Knichel,  2001] 

4.2.4.6  The  Value  of  Modeling  and  Simulation 

Modeling  and  simulation  can  give  insights  into  potential  system  performance  and 
methods  of  employment.  [Landry,  2001] 

Thus,  resources  for  Modeling  and  Simulation  (M&S)  should  be  allocated  quite  early  in  the 
program. 

M&S  may  substitute  when  prototypes  are  not  available.  [Hudson,  2001] 

The  UGV/S  JPO  Robotic  Acquisition  through  Virtual  Environments  and  Networked 
Simulations  (RAVENS)  initiative  is  designed  to  assist  in  the  following: 

V  Requirements  development 

V  Technology  development  and  evaluation 

V  Risk  reduction 


4  Ibid 

5  Paragraph  4a  of  the  Operational  Requirements  Document  shall  contain  information  on  the  required 
performance  capabilities  of  the  system  to  be  acquired  in  relationship  to  its  relevant  mission  scenarios,  and 
include  key  performance  parameters.  CJCSI  3 170.1  A,  Requirements  Generation  System,  10  August  1999. 


54 


•S  Tactical  innovation 

■S  Operational  assessment.  [Hudson,  2001] 

Existing  simulations  may  need  to  be  re-scaled  to  accommodate  factors  relevant  to 
operation  of  robots.  [Hudson,  2001] 

4.2.4.7  Requirements  Process 

Getting  users  involved  early  keeps  the  program  relevant,  but  users  are  not  very 
patient  and  expect  a  lot  more  than  the  vehicles  can  deliver.  [Haug,  2001] 

Must  understand  (and  contain)  the  user  requirements.  Useful  to  scope  the  problem  in 
terms  of  mission  scenarios.  This  will  make  it  possible  to  clarify  the  payback  -  e.g. 
lives  saved.  [Toscano,  2001] 

Deal  with  the  environmental  requirements  from  the  get  go.  Don't  put  it  off.  The  cost 
to  add  it  in  after  the  design  is  completed  is  considerably  more  than  doing  it  up  front. 

It  will  add  some  costs  to  the  system  but  will  greatly  enhance  its  ability  to  operate  in 
rain,  cold,  snow,  etc.  [Anderson,  2001] 

In  defining  the  requirements: 

S  Consider  all  possible  end  users,  have  they  met  and  agreed  upon  the  requirements? 

Some  systems  may  have  multiple  requirements  for  different  users. 

S  Consider  all  possible  operating  temperatures?  Does  the  system  truly  have  to 
operate  at  -25F? 

■S  Consider  EMI.  Has  the  IPT  determined  what  operating  systems  may  affect  your 
system  and  will  your  system  interfere  with  other  systems  in  an  operational 
scenario?  Hardening  for  EMI  can  be  costly  but  necessary;  the  user  must 
determine  what  level  of  protection  is  required. 

■S  Consider  Human  Factors.  Have  soldiers  evaluate  and  comment  on  your  design  at 
ever  opportunity.  Especially  important  when  designing  a  system  that  must  be 
operated  manually  or  by  robotics  depending  on  the  situation.  The  robotic 
operation  must  emulate  the  manual  operation  as  much  as  possible. 

S  Consider  all  possible  restrictions  on  radio  frequencies  used  by  your  system.  In 
peacetime,  soldiers  must  train.  Can  your  frequency  be  used  overseas  and  in  the 
United  States? 

•S  Consider  Built-in-Test  (BIT)  capability,  though  this  will  be  software  intensive. 

■S  Consider  early  consensus  on  hardening  requirements:  Must  your  system  hold  up 
in  tough  terrain  environments  that  will  vibrate  the  system  often  and  continuously? 
Severe  vibration  will  cause  damage  over  time.  [Folk,  2001] 

But,  avoid  war-stories  as  the  basis  for  requirements.  [Schempf,  2001] 

Make  sure,  and  I  reiterate,  make  sure  that  the  organization  that  is  developing  the 
requirements  understands  the  limitations  of  technologies.  We  call  this  expectation 
management.  Work  closely  with  them  in  developing  their  requirements.  [Anderson, 
2001] 
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Separate  the  must  have  requirements  from  the  like  to  have,  then  compare  the 
cost/benefits  of  the  like  to  have.  Attach  a  mission  scenario/justification  to  each  must 
have  requirement.  Don't  let  outliers  define  the  requirements.  Go  after  the  most 
common  problem.  Don't  worry  about  exceptions  or  clever  means  to  counter. 

[Schempf,  2001] 

The  Kepner-Tregoe  (KT)  decision  analysis  process  for  trade  studies  involves  the 
following  steps: 

S  determine  scope. 

•f  list  the  musts  (those  metrics  if  failed  eliminate  the  candidate  solutions). 

S  list  the  wants  and  their  relative  weights,  [low  risk  and  low  cost  may  be  a  want  or 
a  must] 

•f  identify  the  candidate  solutions  and  their  characteristics  with  respect  to  the  musts 
and  wants. 

■f  filter  the  candidates  with  respect  to  the  musts. 

■f  score  the  remaining  candidates  with  respect  to  the  wants  and  total. 

■f  perform  cost  and  risk  analysis  on  the  top  scoring  candidates,  [if  not  already 
considered]  [Gothard  et  al.,  1998] 

Prioritize  requirements.  Implement  the  critical  features  first.  Avoid  the  temptation  to 
add  bells  and  whistles  before  attaining  basic,  required  functionality  that  is  reliable. 

[Heath-Pastore,  2001] 

It  is  valuable  to  understand  the  technology  readiness  for  the  requirements,  and  the 
relevancy  and  adequacy  of  the  requirements  for  the  objective. 

For  example, 

. .  .detecting  mines  is  extremely  difficult  -  are  the  requirements  consistent  with  the 
objective.  [Weisbin,  2001] 

Can  the  requirements  be  met  with  the  current  state  of  the  technology? 

If  the  VSW  MCM  system  is  expected  to  be  fielded  in  three  years,  then  there  is  an 
implicit  assumption  that  the  required  technology  is  ready  today.  [Weisbin,  2001] 

Put  together  an  integrated  system  concept  for  all  of  the  required  capabilities,  and  run 
that  by  the  users  for  reality  checking.  Ask  if  it  is  too  big,  too  expensive,  too 
complicated,  too  hard  to  use,  etc.  [Schempf,  2001] 

If  technology  development  necessary  to  accomplish  the  objective  is  too  expensive. 

What  are  the  de-scoping  issues,  plans?  [Weisbin,  2001] 

State  the  level  of  reliability  required  and  do  not  compromise  early  in  the  effort.  DoD 
has  equipment  that  has  designed  in  poor  reliability  which  has  resulted  in  lack  of 
serviceperson  or  commander  confidence  in  the  system.  [Adams,  2001] 
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UUV  system  countermeasures  and  survivability  should  be  considered  early  in  the 
program.  [Landry,  2001] 

Cost  is  an  independent  variable.  [Landry,  2001] 

Yet  different  costs  may  be  traded. 

In  the  area  of  survivability,  it  is  better  to  keep  cost  low,  then  the  product  can  be  more 
dispensable  compared  to  the  costs  of  taking  it  out  of  action.  Another  important 
comparison  however  is  the  cost  of  the  consequences  of  the  threat.  A  relatively  cheap 
mine  could  sink  a  ship,  therefore  it  might  be  better  to  neutralize  the  mine  with  an 
expensive  UUV  in  order  to  save  the  ship.  [Milcetic,  2001] 

The  robot  product  must  be  useful  and  worth  its  price.  [Gage,  1999] 

Expect  and  allow  for  requirements  creep.  [Toscano,  2001] 

The  probability  of  achieving  performance  objectives  in  a  robotic  system,  when  there 
exists  uncertainty  whether  or  not  the  required  technology  is  sufficiently  mature,  can  be 
increased  using  the  following  process  as  described  in  the  MDARS  strategy  publication: 

V  Identify  the  actual  user  requirements  and  describe  these  in  terms  of  needed 
system  functionalities. 

V  Match  these  to  the  specific  technological  needs  required  to  achieve  successful 
implementation. 

V  Break  these  technological  needs  down  into  three  categories: 

■  Those  that  currently  exist  as  state  of  the  art  (i.e.,  commercial-off-the-shelf- 
technology). 

■  Those  likely  to  come  along  in  the  near-term  (i.e.,  within  the  desired 
development  schedule). 

■  Those  that  are  project- specific  and  unlikely  to  be  otherwise  addressed  by 
industry  or  academia. 

V  The  highest  priority  for  allocation  of  government  resources  should  naturally 
be  assigned  to  those  technical  needs  falling  into  the  last  category  above. 

[Everett  et  al.,  1996]6 

The  Program  Office  may  quickly  find  that  a  large  investment  in  technology  R&D  will  be 
required  to  meet  system  performance  objectives.  As  long  as  the  performance  objectives  do 
not  violate  the  laws  of  physics,  the  Program  Office  may  safely  assume  that  a  technological 
capability  could  be  found  that  will  satisfy  the  requirement.  Depending  upon  the  criticality  of 
achieving  those  objectives,  the  Program  Office  can  then  choose  one  of  the  following: 

■  Table  certain  performance  objectives  as  currently  unfeasible  for  lack  of  technological 
capability  -  least  costly  and  least  effective. 


6  H.  R.  Everett,  R.  T.  Laird,  T.  A.  Heath-Pastore,  G.  A.  Gilbreath,  and  R.  S.  Inderieden. 
1996.  “Technical  Development  Strategy  for  the  Mobile  Detection  Assessment  Response 
System-Interior  (MDARS-I).  Technical  Note  1776  (Aug).  Contact  authors  at  SSC  San  Diego. 
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■  Encourage  and/or  otherwise  support  DARPA,  ONR,  and  other  6. 1-6.3 A  projects  to 
accelerate  development  of  the  needed  technologies  -  most  expedient. 

■  Invest  program  dollars  directly  into  technology  development  -  most  costly  and  most 
effective. 

4.2.4.8  Managing  Cost  and  Schedule 

In  pursuing  performance  objectives  it  is  hard  to  keep  costs  down,  and  to  keep  the 
technology  simple.  [Witter,  2001] 

When  managing  schedule  and  performance  goals,  it  is  better  to  reach  the  goals  and  let 
the  schedule  slip.  [Toscano,  2001] 

Many  surprises  can  impact  cost  and  schedule:  the  redesign  of  boards  is  very  time 
consuming;  often  they  will  not  work  the  first  time  as  testing  will  uncover  “bugs”  in 
the  system.  Expect  and  plan  for  “time  and  money”  to  do  reasonable  “test-fix-re test”. 
These  are  complicated  systems  that  require  a  certain  degree  of  time  dedicated  to 
testing  and  redesign.  [Folk,  2001] 

Determine  and  state  cost  and  performance  objectives  early  to  guide  the  PM  in 
developing  the  schedule.  If  the  schedule  considerations  dominate  the  program 
decisions,  there  is  a  good  chance  that  the  system  will  either  cost  more  than  the 
customer  expects  or  may  have  less  performance  than  desired  or  needed.  [Adams, 
2001] 

It  was  useful  to  specify  that  the  contractor  provide  a  second  prototype,  for  the 
engineering  prototype  will  have  to  be  modified  during  operational  testing.  [Folk, 
2001] 

A  successful  prototype  is  generally  dependent  upon  who  does  the  work.  How  will  the 
performer  (contractor)  be  selected?  [Weisbin,  2001] 

4.2.4.9  Contracting 

Consider  when  selecting  a  contractor: 

S  Program  execution  is  easier  if  the  same  contractor  can  do  both  R&D  and 

production.  If  the  contractor  is  strictly  R&D,  do  they  have  competent  people  and 
facilities  to  build  a  sound  prototype? 

■S  Does  the  contractor  have  a  placed  to  test  his  prototype  in  a  field  environment  or 
will  the  first  test  be  at  a  government  facility/range? 

■S  What  is  the  contractor’s  plan  for  quality  assurance;  is  the  QA  plan  already 
implemented  and  in  use  by  the  contractor? 

What  is  the  contractor’s  standard  for  software  engineering?  Do  they  have 
engineers  that  can  truly  check  the  work  of  programmers  and  do  they  have 
appropriate  diagnostic  equipment  to  run  tests? 

■S  What  is  the  contractor  process  for  configuration  management;  is  the  CM  plan 
already  implemented  and  working? 
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■S  What  are  the  contractor's  resources?  Small  contractors  are  prone  to  promise  more 
because  survival  is  at  stake.  Will  this  contractor  “close  his  doors”  if  he  fails  on 
your  contract?  [Folk,  2001] 

As  always,  competition  is  the  key  to  getting  a  good  contractor.  The  robotics  community 
should  pursue  contracting  strategies  that  broaden  the  commercial  base  of  its  suppliers. 

Reliability  of  robotics-related  hardware  is  a  major  concern  to  many  academic  developers. 
These  developers  also  voiced  a  common  complaint  about  the  poor  support  they  received  from 
suppliers,  while  acknowledging  that  the  reason  for  this  may  be  the  non-commercial  nature  of 
the  industry. 

4.2.4.10  Maintaining  a  Successful  Program 

Need  to  introduce  some  low-risk  robot  applications  in  order  to  change  the  culture  and 
pave  the  way  for  more  ambitious  projects,  i.e.  the  robotic  follower  ATD.  [Bornstein 
et  al.,  2001] 

The  most  important  criteria  for  a  successful  program  is  producing  an  end  product  that 
the  user  will  use  and  appreciate.  [Everett  et  al.,  1996] 

Behavioral  robustness  is  required  if  mobile  robots  are  to  find  viable  markets;  the 
designer  must  accommodate  the  full  range  of  variability  within: 

S  The  manufacturing  processes:  no  handcrafting 
S  The  target  operating  environments:  no  manual  "tuning"  [Gage,  2000] 

Select  a  niche  mission  that  can  be  accomplished  cost  effectively.  [Toscano,  2001] 

Do  not  say  "reduce  people",  say  instead,  "make  them  more  effective".  [Bonheim, 

2001] 

Coordination  with  other  robotics  programs  can  be  a  problem.  An  effective  approach 
is  to  share  funding,  or  share  people.  [Toscano,  2001] 

Personalities  are  the  key  to  cooperation  with  other  defense  programs.  [Witter,  2001] 

Personal  relationships  work  best  when  trying  to  influence  DARPA  to  coordinate  with 
your  program.  Then  come  to  DARPA  with  a  developer.  [Dodd,  2001] 

The  PM  or  his  representative  should  participate  in  the  Interagency  Security 
Technology  Exchange 
■S  keep  informed 

S  avoid  paying  twice  for  the  same  capability 

■S  helpful  to  share  programmatic  information  as  well  as  technical  information 

[Witter,  2001] 

Continuously  survey  the  technology  readiness,  constantly  visit  the  developers,  keep 
experts  as  consultants.  Set  up  an  advisory  council.  Council  members  will  generally 
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fund  their  own  participation  just  to  keep  association  with  the  program.  [Jenkins, 

2001] 

Permit  no  harm  to  come  to  domestic  interests  during  development,  testing,  or 
operation,  and  threaten  no  harm  to  friendly  operations.  [Toscano,  2001] 

Congress  and  most  constituents  are  shy  about  the  placement  of  weapons  on  robots. 

[Morrison,  2001] 

Early  UGV  programs  lost  funding  when  program  managers  proposed  arming  the 
vehicles.  Users  are  content  to  "see  better",  rather  than  to  "shoot  sooner".  [Haug, 
2001] 

There  are  at  least  two  practical  factors  that  militate  against  arming  a  robot: 
Inadequate  agility  -  the  robot  will  be  subject  to  hostile  fire  if  it  reveals  its  position. 
Inadequate  physical  security  -  the  robot  cannot  adequately  perceive  or  respond  to 
immediate  threats  in  its  environment  without  human  support.  [Haug,  2001] 

When  faced  with  the  need  to  pursue  something  that  is  politically  sensitive  or 
culturally  controversial,  deflect  cultural  resistance  to  another  issue  that  is 
inconsequential  and  to  which  your  program  can  later  yield.  [Dodd,  2001] 

Money  is  the  most  critical  programmatic  problem.  [Toscano,  2001] 

Maintain  the  stability  of  the  funding  base  [Jenkins,  2001] 

Identify  a  champion  and  nurture  support  from  the  top.  [Toscano,  2001] 

It  would  be  wise  to  look  to  future  issues  just  in  case  you  become  successful  with  the 
present  project  objectives.  [Toscano,  2001] 

4.3  Technologies 

4.3.1  Lessons  Relevant  to  Sensor  Technologies 

Apply  the  right  sensor  for  the  type  of  control  required  [Gothard  et  al.,  1993], 

Effective  fusion  of  redundant  sensors  is  the  key  to  robust  operation.  [Everett,  2001] 

Be  prepared  to  replace  some  sensors  that  are  found  inadequate,  because  the  final 
environment  is  very  hard  to  predict  [Gothard  et  al.,  1993]. 

Don't  depend  on  a  single  sensor  technology,  sensors  LIE!  [Klarer,  2001] 

If  the  environment  changes,  go  back  and  check  each  sensor  to  see  if  the  change  had 
an  adverse  effect  on  the  sensors.  [Gothard  et  al.,  1993] 

Adaptive  sensors  would  help  greatly  with  this  problem. 
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Choose  sensor  phenomenology  that  differentiates  vs.  "just  detects",  that  penetrates 
environmental  and  terrain  features  as  required,  and  minimizes  algorithmic  processing 
to  get  useful  information.  [Gothard  et  al.,  1998] 

Demo  III  views  the  autonomous  navigation  problem  as  a  feature  classification 
problem.  [Rosenblum  et  al.,  1998] 

Autonomous  robotic  mobility  requires  redundancy  in  both  sensors  and  algorithms 
employed  for  both  reliability  and  robustness.  [Rosenblum  et  al.,  1998] 

Redundancy  in  sensors  permits  a  combination  of  phenomenologies  of  the  sensors  that 
implicitly  provides  contrast  to  easily  segment  out  the  hazardous  features  of  the  scene. 

[Rosenblum  et  al.,  1998] 

Criteria  include  reliability,  robustness,  self-adapting,  and  low  cost.  Requirements  for 
component  accuracy  should  be  reduced  while  increasing  simultaneously  the  accuracy 
of  the  resultant  capabilities.  Similar  to  the  objective  to  reduce  accuracy  is  to  reduce 
the  need  for  data  resolution.  [Rosenblum  et  al.,  1998] 

In  multi-sensor  systems,  difficulty  is  encountered  in  correlating  sensors  with  respect 
to  the  same  target.  [Thorpe,  2001] 

If  a  complex  robot  is  to  operate  robustly,  its  world  model  must  take  adequate  account  of 
the  relevant  dimensions  of  variability  of  the  environment,  as  they  will  be  reported  by  the 
sensor  subsystems. 

■S  A  robot's  world  model  is  much  simpler  than  a  human's. 

S  Unintended  aspects  of  the  model  can  creep  in  as  consequences  of  various 
software  design  decisions 

■S  The  developer  must  understand  the  limits  of  his  system's  world  model  [Gage, 

2000] 

Consider  chemical  sensors,  consider  a  fish  that  is  either  trained  or  controlled  by 
implanted  electrodes.  [Brooks,  2001] 

The  logic  behind  the  above  suggestion  is  that  most  unique  artifacts  in  the  water  should 
release  traceable  chemicals  that  will  diffuse  along  a  gradient.  Most  animals,  both  marine  and 
terrestrial,  are  designed  to  track  along  such  gradients.  The  trick  is  to  train  a  fish  to  orient  to  a 
particular  chemical  and  then  to  control  its  tropic  behavior  so  that  it  approaches  the  source  of 
the  diffusion.  The  fish  could  loiter  about  the  source  until  it  expires  or  until  the  tropic  control 
stimulus  is  removed.  Such  fish  could  also  involuntarily  transport  pingers  or  detonators.  Small 
sharks  or  rays  might  be  good  candidates.  Because  of  the  natural  abilities  of  the  fish  to 
negotiate  obstacles,  swim  in  and  against  currents,  and  find  sources  of  energy  (feed 
themselves),  their  employment  could  already  solve  many  of  the  troublesome  problems  facing 
the  use  of  small  unmanned  underwater  vehicles.  With  the  proper  placement  of  electrodes  in 
the  fish  brain,  training  requirements  could  be  minimized,  thus  significantly  reducing  costs. 
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Figure  12.  Manta  Ray  candidate  for  hybrid  VSW  MCM  application. 

Some  other  issues  that  must  be  addressed  in  this  hybrid  approach  are  reliability, 
communications/control  and  re-tasking,  zone  coverage,  and  recovery  and/or  disposal  of 
surplus  agents. 

Other  common  residents  of  the  shallow  water  and  SZs  that  might  be  used  in  mine 
detection  and  neutralization  include  lobsters  and  octopi.  The  latter  have  excellent  visual  and 
tactile  abilities,  and  can  be  operantly  trained  and  controlled  by  electrical  brain  stimulation. 
DARPA  is  exploring  technologies  relevant  to  this  approach  [DARPA]. 

Tactile  sensors  of  equivalent  utility  for  UUVs  do  not  currently  exist. 

Tactile  sensors  are  not  well  developed.  But  one  strategy  might  be  to  tow  in  a  sensor 
net  that  detects  targets  by  contact  and  provides  simultaneous  mapping  information. 
Like  a  spider  web  the  sensor  net  could  guide  other  vehicles  that  place  charges  on 
verified  obstacles  and  mines.  [Schempf,  2001] 

4.3.2  Lessons  Relevant  to  Communications  and  Control  Methods 

The  biggest  risk  area  for  the  overall  unmanned  systems  area  is  adequate  assured 
communications  capabilities  and  the  development  and  fielding  of  new,  mature 
command  and  control  capabilities  that  are  specifically  capable  of  providing  the  man- 
unmanned  team  interfaces  and  capabilities  without  over-burdening  the  soldiers  and 
staff  with  unnecessary  interruptions  or  workload.  [Dodd,  2000] 

Antenna  height  is  one  of  the  most  important  aspects  of  RF  performance.  If  you  want 
to  enhance  your  data-link  performance,  raise  the  antenna  several  wavelengths  above 
the  nearest  surface.  At  the  4.4-5.85  GHz  band  we  implemented  a  pneumatic  mast  to 
raise  the  antenna  to  a  height  of  43  feet.  Works  great!  Antenna  directionality  (gain)  is 
next.  Must  have  gain  at  least  on  the  receiving  end.  A  method  to  put  directional  gain 
on  a  moving  vehicle,  cheaply  and  easily,  would  be  a  great  enhancement.  Utilize  the 
lowest  loss  cabling  and  connectors  you  can  find.  When  you  raise  the  antenna  you  add 
cable  length.  If  the  correct  cable  is  not  used,  your  losses  can  offset  the  gains  you  get 
from  height.  Utilize  filtering  and  pre-amps  to  the  maximum.  You  can't  filter  too 
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much.  Make  sure  the  antennas  are  mounted  correctly  on  the  robot  and  the  operator 
control  unit.  We  had  an  occurrence  where  we  were  creating  nulls  in  the  antenna 
pattern  because  the  antenna  system  was  not  addressed  during  the  development  of  the 
overall  system.  It  has  to  be  an  integral  part  of  the  system  engineering  process. 

Conduct  antenna  pattern  testing  early  in  the  design  to  ensure  that  the  problem  is  not 
present.  [Anderson,  2001] 

I've  seen  too  many  systems  that  REQUIRE  high  bandwidth  communications  such  that 
they  are  hamstrung  unless  they  have  multi-megabit  bandwidth.  Our  approach  has 
been  to  drive  communications  bandwidth  requirements  down  as  far  as  possible,  and 
force  ourselves  to  live  with  reduced  communications.  This  has  driven  our  algorithms 
and  controls  approaches  to  be  efficient  and  effective.  My  advice:  DO  NOT  LISTEN 
to  anyone  who  tells  you  that  communication  bandwidth  reduction  is  not  an  issue... it 
is,  it  will  always  be,  and  it  will  only  get  worse  over  time.  [Klarer,  2001] 

Define  (or  adopt)  a  communication  interface  between  the  command  and  control 
station  and  the  remote  vehicle  that  supports  a  layer  of  abstraction.  The  future  can 
bring  changes  to  both  the  vehicle  and  the  control  station  or  another  vehicle  type  may 
be  desired/required.  This  is  reasonable  to  accommodate  with  a  higher-level  interface 
specification  defined,  but  nearly  impossible  if  the  control  station  and  vehicle  have  a 
low-level  intertwined  relationship.  [Heath-Pastore,  2001] 

One  of  the  major  concerns  of  military  decision-makers  relative  to  the  deployment  of 
UGVs  is  the  problem  with  maintaining  reliable  communication.  Not  too  long  ago 
(early  90’s),  it  was  nearly  impossible  to  have  multiple  indoor  robots  or  UAVs 
communicating  at  a  decent  rate  without  severe  problems,  as  was  observed  regularly  at 
competitive  robot  events.  Georgia  Tech  adopted  commercial  ISM  band  frequency- 
hopping  data  links  for  this  application,  and  we’ve  been  quite  satisfied  with  the 
performance  of  this  equipment  in  relatively  benign  indoor  and  outdoor  conditions, 
including  both  ground  and  aerial  vehicles.  But  the  difficulty  of 
maintaining/configuring  point-to-point  links,  combined  with  the  trend  towards 
simultaneous  operation  of  more  vehicles,  has  driven  me  toward  a  related  COTS 
technology,  802.1 1  wireless  LAN.  The  ease  of  use  is  much  greater,  but  with 
significant  reduction  of  range  (from  0.5-1  mile  down  to  100-500  feet,  typically). 
Raytheon  developed  longer-range  down-converters  that  could  be  used  as  front-ends 
on  COTS  802.1 1  devices,  and  these  were  demonstrated  successfully  at  the  DARPA 
Tactical  Mobile  Robotics  (TMR)  demonstrations  in  2000.  It’s  not  clear  how 
applicable  any  of  these  RF  experiences  would  be  to  UUVs.  As  an  occasional  diver, 
I’m  aware  of  the  absorption  of  visible  light  (most  strongly  toward  the  red  end  the 
spectrum),  but  I  have  wondered  whether  there  is  some  visible  or  near- visible  band 
that  would  be  suitable  for  underwater  communication,  at  least  in  short-range 
applications  such  as  the  coordination  of  many  EOD  UUVs  in  a  harbor  operation. 

Also,  it’s  worth  noting  that  a  great  deal  of  cooperative  behavior  can  be  accomplished 
without  explicit  communication.  Simply  by  observing  other  robots  (or  the  effects  of 
other  robots  on  the  environment),  a  robot  can  implicitly  understand  the  intents  and 
actions  of  other  robots.  This  phenomenon  is  observed  in  biological  systems 
(schooling,  flocking,  coordinated  predator  responses,  etc.),  and  we  have  utilized  it  in 
robot  foraging  experiments.  [Collins,  2001] 


63 


Visual  coordination  is  undeniably  involved  in  the  schooling  of  fish.  Fish  also 
communicate  using  modulations  of  electrical  potentials  in  the  lateral  line  organ  for 
coordination  during  schooling.  These  methods  work  primarily  on  nearest  neighbors  and 
poorly  at  a  distance.  Whether  information  is  broadcast  by  whole  body  behaviors  or  by 
modulations  of  electrical  potentials,  the  observation  of  those  changes  of  state  are  necessary 
for  communication,  and  it  is  the  difficulty  of  RF  transmission  in  the  water  that  makes  the 
reception  (observation)  of  RF-mediated  communications  difficult. 

A  major  drawback  to  the  digital  video  system  used  in  the  MPRS  prototype  was  the 
high  bandwidth  requirement  and  hence  the  requirements  for  a  WLAN  modem  and  the 
high  frequencies  employed  by  these  radios.  Because  of  the  low-power  and  high- 
frequency  characteristics  of  these  radios,  the  communications  opportunity  was 
generally  limited  to  LOS.  However,  the  tunnel  environment  often  acted  as  a  wave 
guide,  facilitating  transmission.  [Bruch  et  al.,  2000] 

The  frame  rate  of  the  visual  feed  to  Demo  III  operators  was  too  slow  [Burns  et  al., 

2000], 

Of  the  information  to  be  communicated,  we  may  define  three  categories: 

■  Vehicle  status. 

■  Mission  status. 

■  Environmental  status. 

Like  most  major  centers  of  mobile  robot  research,  Georgia  Tech  adopted  behavior- 
based  control  techniques,  but  unlike  many  others,  they  have  long  championed  the  use 
of  hybrid  architectures  which  also  include  a  deliberative  supervisory  component  (like 
the  higher-level  mapper  capability  mentioned  in  the  previous  section).  Hybrid 
architectures  provide  the  robust  behavior  and  quick  response  characteristic  of 
behavior-based  control  while  still  allowing  for  organized  planning  and  high-level 
structured  behavior.  The  complexity  which  inevitably  results  from  a  sophisticated 
hybrid  control  architecture  can  be  mitigated  with  machine  learning  techniques. 
Currently,  in  the  DARPA  Mobile  Autonomous  Robot  Software  (MARS)  program, 
we’re  integrating  learning  at  five  levels  within  the  architecture,  from  online 
adaptation  of  behavioral  parameters  all  the  way  up  to  techniques  for  improving  the 
skills  of  the  human  who  defines  missions.  [Collins,  2001] 

The  biggest  risks  for  the  overall  unmanned  systems  area  are  adequate  assured 
communications  capabilities  and  the  development  of  new,  mature  command  and 
control  capabilities.  [Dodd,  2001] 

Again,  what  makes  communications,  command,  and  control  so  important  in  unmanned 
systems  is  the  lack  of  reliable  autonomy,  versus  automaticity,  in  the  unmanned  systems. 
Automatic  systems  will  go  their  preprogrammed  way  unless  interrupted  by  exceptions,  at 
which  point,  the  operator  is  called  back  into  the  control  loop.  Without  communications,  the 
interruption  could  be  quite  extended.  Less  automaticity  and  greater  autonomy  would  permit 
the  unmanned  systems  to  achieve  mission  objectives  by  exercising  real-time  re-planning  and 
adaptations  to  changing  and  unexpected  conditions. 
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Without  autonomy,  the  robots  are  simply  extended  tools.  With  automaticity,  the  robots  are 
fancy  tools,  but  tools  none-the-less,  ultimately  dependent  upon  human  control,  and  upon 
communications  to  maintain  that  control. 

If  our  communications  capabilities  are  going  to  be  in  doubt,  then  we  must  be  willing 
either  to  reduce  our  remote  functionality  or  to  permit  the  remote  autonomy. 

4.3.2.1  Methods  of  Control 

On  our  operator  control  units,  we  typically  have  all  sorts  of  buttons,  switches, 
displays,  etc.  The  more  you  have,  the  more  problems  you  have.  You  have  problems 
with  joysticks  breaking,  displays  not  working  in  cold  weather,  water  leaks,  etc. 

Think  minimum  on  switches,  etc.  Maybe  have  some  sort  of  software  interface  or 
touch  screen.  We  are  developing  a  system  now  with  only  a  touch-screen  for  the 
operator  to  interface  with.  [Anderson,  2001] 

Make  the  control  system  as  plug  and  play  as  possible.  Modularity  is  great!  Our 
experience  is  that  when  we  give  a  soldier/marine  a  system  with  capabilities,  they 
always  want  to  add  more.  Think  modularity  and  expandability.  Logistics  guys  love 
this  too.  [Anderson,  2001] 

Conventional  control  methods  have  proven  perfectly  adequate  for  everything  we've 

done  to  date . elaborate  or  complex  schemes  are  great  conference  paper  material 

but  are  not  necessarily  appropriate  for  our  customers.  For  ANYTHING  military,  you 
MUST  prove  stability  and  robustness  for  safety  and  reliability  considerations. 

[Klarer,  2001] 

Robot  control  strategies  must  expect  the  unexpected,  prepare  for  uncertainty  [Thrun, 

2001] 

4.3.2.2  Mixed  Initiative  Control 

A  major  research  question  remains:  how  to  handle  mixed  initiative  control? 

[Swinson,  2001] 

Mixed  initiative  is  the  situation  when  the  human  operator  and  the  onboard  control 
algorithms  are  simultaneously  attempting  to  direct  the  vehicle. 

No  one  will  let  absolutely  dumb  vehicles  into  the  operating  environment  without 
complete  human  control,  but  the  vehicles  must  have  some  minimal  level  of 
competency,  i.e.  obstacle  avoidance.  [Swinson,  2001] 

Humans  are  far  from  being  error-free  and  high-reliability  cohorts.  Thus,  with  humans 
introducing  an  additional  element  of  uncertainty  into  the  control  loop  of  a  vehicle  that  is 
supposed  to  reactively  negotiate  in  real-time  obstacles  and  other  unknowns  in  its  path,  robots 
may  have  to  exercise  more  adaptive  capabilities  than  if  they  were  left  to  their  own  devices. 

We  spend  a  lot  of  money  on  the  platforms,  but  do  not  get  to  address  the  critical  issues 
of  control.  [Swinson,  2001] 
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Related  to  the  problem  of  mixed  initiative  is  the  problem  of  embedded  software. 

Part  of  the  problem  of  embedded  software  is  the  communication  among  developers, 
because  people  with  domain  experience  in  the  application  have  no  software 
competency,  and  because  the  good  software  engineers  do  not  understand  the  physics 
and  engineering  problems.  Second  is  the  problem  of  how  to  instantiate  the  different 
levels  of  competency.  [Swinson,  2001] 

4.3.3  Lessons  Related  to  Other  Technology  Issues 

4.3.3.1  MDARS  Lessons  Learned 

The  MDARS -I  project  literature  refers  to  an  experience  in  which  the  robot  failed  to 
perform  adequately  after  it  was  moved  from  one  developmental  environment  to  a  different 
test  environment.  The  MDARS-I  team  called  this  phenomenon  system  shock,  and  considered 
it  a  problem  of  fundamental  importance  and  common  occurrence: 

■f  The  MDARS-I  developers  learned  that  moving  a  robot  from  one  environment  to 
another  created  unanticipated  problems;  typical  causes  include: 

S  hardware  and  software  errors  that  had  not  been  manifested  in  the  previous 
environment; 

■f  sensor  modes  or  processing  algorithms  tuned  too  tightly  to  specific  characteristics 
of  the  initial  development  environment; 

■f  subtle  interactions  between  limitations  in  multiple  hardware  and  software 
components  .  [Gage,  2000] 

A  key  lesson  is  that  system  robustness  can  only  be  ensured  by  exhaustively 
exercising  its  operational  capabilities  in  a  number  of  diverse  environments.  This 
approach  helps  uncover  latent  system  hardware  deficiencies  and  software 
implementation  errors  not  manifested  in  the  initial  system  hardware  or  initial 
development  environment.  [Everett  et  al.,  2001] 

The  MDARS-I  team  suggest  a  solution  to  the  fundamental  cause  of  "system  shock"  in 
their  next  paragraph. 

A  human's  perceptual  capabilities  are  powerfully  adept  at  characterizing  both  the 
similarities  and  differences  between  various  features  of  his/her  environment  -  at 
detecting  both  the  general  rule  and  the  specific  exception  to  it.  A  robot's  sensory 
inputs,  on  the  other  hand,  are  far  more  limited,  as  it  can  interpret  these  inputs  only  up 
to  the  limits  of  its  environmental  model.  [Everett  et  al.,  2001] 

But  the  authors'  explanation  is  that  "the  robot's  implicit  world  model  is  not  rich  enough  to 
support  the  behaviors  required  by  the  application." 

An  alternative  explanation  is  that  the  world  models  that  the  human  programmer  and  users 
are  able  to  talk  about  have  little  to  do  with  adaptability.  In  this  alternative,  adaptability  is 
dependent  upon  the  presence  of  fundamental  reflexes  that  subserve  all  developments  and 
employments  of  higher  world  models  in  any  member  of  any  species. 
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Without  the  appropriate  fundamental  reflexes  installed  in  a  robot,  the  programmer  and 
user  will  be  continuously  trying  to  predict  the  exceptions  to  high-level  rules  that  the  robot 
will  encounter,  and  predict  the  appropriate  changes  in  operational  parameters  that  will 
compensate  for  those  exceptions.  The  attempt  to  predict  compensatory  adjustments  must  be 
performed  open  loop,  and  thus  without  the  possibility  of  feedback,  is  at  high  risk  for  failure. 

The  authors  conclude  the  following: 

Behavioral  robustness  is  required  if  mobile  robots  are  to  infiltrate  viable  markets. 
Truly  practical  robots  must  be  mass  producible,  rather  than  handcrafted,  and  they 
must  function  acceptably  over  as  wide  a  range  of  environments  as  possible  without 
excessive  manual  tuning.  Thus  the  designer  of  mobile  robotic  hardware  and  software 
must  accommodate  the  full  range  of  variability  within  manufacturing  processes  and 
within  target  operating  environments,  or  face  the  consequences  in  the  form  of 
unreliable  real-world  performance.  [Everett  et  al.,  2001] 

The  solution  is  to  provide  a  basis  for  perception  and  performance  that  is  not  entirely 
dependent  upon  a  specified  world  model. 

4.3.3.2  Human/Robot  Interactions 

Mobile  robots  deployed  in  real-world  applications  must  of  necessity  be  capable  of 
successfully  interacting  with  humans,  the  operators  who  task  them  and  monitor  their 
performance  as  well  as  those  who  by  plan  or  happenstance  share  the  robots' 
workspace.  [Everett,  2001] 

The  design  of  the  robots  and  the  concept  for  their  operation  must  consider  not  only  the 
habits  and  requirements  of  their  operators,  but  also  the  habits  and  propensities  of  people  who 
might  encounter  the  robots  during  mission  performance.  People  in  the  robot's  environment 
could  be  cooperative,  indifferent,  hostile,  or  just  curious.  The  expression  of  each  of  those 
different  attitudes  could  have  significant  consequences  on  the  safety  and  effectiveness  of  the 
robot. 

The  MDARS  project  also  discovered  that  the  dual  use  of  robot  sensors  for  automatic  robot 
navigation  and  teleoperation  posed  difficulties.  The  problem  here,  though,  is  due  more  to  an 
incomplete  satisfaction  of  operator  information  needs.  Teleoperation  presents  many 
difficulties  that  can  be  either  mollified  or  exacerbated  by  robot-initiated  behaviors.  Many 
computer  users  experience  something  similar  to  this  when  keyboard  commands  are  ignored 
by  their  computers,  or  when  something  quite  unexpected  results  from  a  commanded  action, 
either  of  which  could  have  saved  the  user  from  a  greater  grief,  had  the  user  been  aware  of  his 
action's  consequences. 

Developers  of  robots  must  remember  that  their  users  have  not  had  the  benefits  of  many 
years  of  developmental  experience  with  their  robots.  Little  about  the  robot  should  be  assumed 
as  intuitive  to  the  user.  In  summary,  the  authors  advise  the  following: 

■S  Display  information  in  terms  meaningful  for  the  operator:  rather  than  presenting  a 
number  representing  battery  voltage,  show  percentage  of  charge  remaining,  or 
operating  time  remaining,  preferably  in  graphical  format.  Use  color  to 
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differentiate  "plenty  of  power"  from  "power  getting  low",  and  add  an  audio  alert 
for  "power  dangerously  low". 

■S  Make  clear  to  the  user  what  action(s)  he  or  she  is  expected  to  perform.  If  a  simple 
acknowledgment  is  desired,  then  the  system  should  display  a  single  big  "OK" 
button,  with  the  cursor  already  placed  on  it.  Do  not  display  options  that  are  not 
currently  available  as  grayed-out  icons — make  them  completely  invisible. 

Provide  a  brief  top-level  explanation  of  what  is  going  on  with  graphics  or  large 
bold  text,  with  supporting  details  available  but  not  intrusive. 

•S  Automatically  monitor  system  state  proactively  and  defensively. 

S  Understand  the  users — understand  the  job  they  are  assigned  to  do,  how  they  do 
that  job,  and  their  level  of  education,  training,  and  experience. 

S  Second,  respect  the  users — listen  to  their  concerns  and  suggestions.  And 
remember  that  they  will  have  the  final  say  in  judging  whether  the  robot 
application  is  a  success  or  failure. 

S  Third,  support  the  users — make  it  as  easy  as  possible  for  them  to  provide  the 
appropriate  inputs  to  the  robotic  system  in  every  situation,  and  for  them  to  be 
successful  in  doing  their  jobs. 

■S  Finally,  work  very  hard  to  make  the  system  "user-proof — make  it  as  difficult  as 
possible  for  them  to  make  inappropriate  inputs  to  the  system.  [Everett  et  al., 
2001] 

4.3.3.3  Mobility  and  Methods  of  Locomotion 

RSTA  is  a  most  difficult  task.  Two  of  the  biggest  problems  are  mobility  and 

communications.  In  smaller  systems,  power  becomes  a  major  consideration. 

[Toscano,  2001] 

In  urban  search  and  rescue  (mostly  work  under  rubble  following  disasters  such  as  a 
building  collapse),  an  environment  not  too  dissimilar  to  the  underwater  environment  with 
regard  to  physical  constraints,  the  major  problems  are  communications  with  the  robot, 
sensors,  power  density  and  duration,  and  just  getting  around  in  the  rubble.  Disabled  robots 
are  as  good  as  lost. 

If  an  agent  is  competently  mobile,  then  it  should  be  able  to  get  along  without  constant 
supervision.  This  mobility  would  reduce  the  dependence  of  the  vehicle  upon 
communications.  But  we  have  seen  in  the  example  of  the  urban  search  vehicle,  that  even 
excellent  communications  cannot  salvage  a  vehicle  that  becomes  stuck  in  rubble.  Mobility  as 
a  system  capability  should  be  given  a  higher  priority  than  communications. 

If  we  are  going  to  use  machines  in  the  defense  of  our  resources,  whether  those  resources 
are  fixed  and  our  adversaries  are  mobile,  or  our  resources  are  mobile  and  the  threats  to  our 
resources  are  fixed  (as  are  some  mines),  and  if  we  do  not  wish  to  man  those  machines,  then 
we  must  make  sure  that  the  machines  in  our  absence  have  adequate  mobility,  and  adequate 
information  gathering  and  processing  functionality  to  accomplish  effective  tactical 
maneuvers  that  maintain  their  separation  from  the  threats. 

Our  machines  cannot  now  independently  govern  their  own  mobility.  As  simple  a 
requirement  as  obstacle  avoidance  in  an  untended  machine  is  extremely  difficult  to  provide  in 
unpredictable  real-world  environments.  The  problems  of  machine  target  detection,  and  of 
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machine  prediction  of  the  behaviors  of  other  mobile  agents,  have  largely  remained  unsolved. 
Rather,  machines  require  intensive  and  costly  human  attention  for  control  in  any  but  the  most 
structured  and  benign  environments.  The  remote  monitoring  and  control  of  an  unmanned 
vehicle  actually  increases  human  labor  and  decreases  the  overall  effectiveness  of  the  system 
compared  to  a  manned  presence.  This  result  is  the  consequence  of  the  increased  difficulty  of 
human  intervention  in  events  beyond  normal  human  sensor  ranges  and  beyond  the  normal 
human  reach.  Thus,  at  the  present,  our  systems  of  remotely  controlled  machines  and 
operators  are  at  a  great  disadvantage  when  assigned  to  the  tasks  of  protecting  and  preserving 
our  resources  under  competition  with  highly  maneuverable  manned  threats. 

The  MPRS  project  discovered  that  its  prototype  robot,  the  URBOT,  was  not  fast 
enough  to  keep  up  with  the  momentum  of  an  attack.  During  an  attack  on  a  city, 
momentum  is  everything;  if  someone  or  something  cannot  keep  up  it  gets  left  behind. 

[Bruch  et  al.,  2000] 

Tactically  speaking,  a  sluggish  agent  gets  out-maneuvered,  overtaken,  and  overpowered. 

Professor  Benjamin  Brown  of  the  Robitics  Institute  at  Carnegie  Mellon  University  has 
produced  and  interesting  mobile  robot  composed  of  a  single  gyroscopically  controlled  wheel. 

Gyrover  is  a  single-wheel  robot  that  is  stabilized  and  steered  by  means  of  an  internal, 
mechanical  gyroscope.  Gyrover  can  stand  and  turn  in  place,  move  deliberately  at  low 
speed,  climb  moderate  grades,  and  move  stably  on  rough  terrain  at  high  speeds.  It  has 
a  relatively  large  rolling  diameter  which  facilitates  motion  over  rough  terrain;  a  single 
track  and  narrow  profile  for  obstacle  avoidance;  and  is  completely  enclosed  for 
protection  from  the  environment.  [Brown,  2000] 

In  addition  to  those  advantages  cited  above  for  a  single- wheel  vehicle,  there  are 
potentially  a  number  of  additional  advantages  to  this  concept  over  multi-wheeled 
vehicles: 

■S  Gyrover  is  resistant  to  getting  stuck  on  obstacles  because  it  has  no  body  to  hang 
up,  no  exposed  appendages,  and  the  entire  exposed  surface  is  "live"  (driven). 

■S  The  tiltable  flywheel  can  be  used  to  right  the  vehicle  from  its  statically  stable,  rest 
position  (on  its  side). 

■S  The  wheel  has  no  "backside"  on  which  to  get  stuck. 

■S  The  entire  system  can  be  enclosed  within  the  wheel  to  provide  mechanical  and 
environmental  protection  for  equipment  and  mechanisms. 

S  Gyrover  can  turn  in  place  by  simply  leaning  and  preceding  in  the  desired 
direction — with  no  special  steering  mechanism — enhancing  maneuverability. 

■S  Single-point  contact  with  the  ground  eliminates  the  need  to  accommodate  many 
contact  points  and  simplifies  control. 

•S  Full  drive  traction  is  available  because  all  the  weight  is  on  the  single  drive  wheel. 
■S  A  large  pneumatic  tire  may  have  very  low  ground-contact  pressure,  resulting  in 
minimal  disturbance  to  the  surface  and  minimum  rolling  resistance. 

■S  The  tire  may  be  suitable  for  traveling  on  soft  soils,  sand,  snow  or  ice;  riding  over 
brush  or  other  vegetation;  or,  with  adequate  buoyancy,  for  traveling  on  water. 
[Brown,  2000] 


69 


Figure  13.  CMU  GYROVER. 


SANDIA  National  Laboratories  has  invented  a  combustion-powered  hopping  platform 
under  DARPA  sponsorship.  The  platform  was  designed  for  military  surveillance  applications 
[SANDIA],  Hopping  may  be  the  next  best  thing  to  flight  to  avoid  obstacles  on  the  ground, 
but  control  is  lacking  during  the  ballistic  phase  of  the  hop.  Hopping  should  have  promise  as  a 
launching  mechanism  and  as  an  escape  mechanism.  The  unpredictability  of  hopping  could  be 
a  benefit  for  self-preservation.  Insects  suffer  no  ill  effects  of  random  landings  because  their 
mass  and  velocity  products  are  too  small.  Similarly,  only  the  smaller  robots  should  be  able  to 
take  advantage  of  hopping  for  mobility.  The  SANDIA  hopper  represented  in  Figure  14 
performs  100  jumps  from  10  to  20  feet  in  the  air  on  a  single  tank  of  fuel. 


Figure  14.  SANDIA  researcher  Gary  Fischer's  combustion-powered  hopping  robot. 
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4.3.3.4  Power  Technologies 

Commercial  battery  technologies  are  getting  pretty  good,  we've  stuck  pretty  much 
with  lead-acid  gel  cells  for  all  but  the  most  demanding  of  applications  simply  due  to 
their  simplicity  and  availability.  More  exotic  technologies  with  higher  power  density 
have  pitfalls  that  can  be  highly  problematic,  and  require  things  like  automatic 
shutdown  to  prevent  over-current  conditions.  [Klarer,  2001] 

SANDIA  Laboratory  has  experimented  with  fuel  cells  in  the  SANDIA  RATLER  vehicle. 
Several  important  lessons  were  learned,  but  are  as  yet  unpublished.  Interested  parties  should 
contact  Paul  Klarer  at  SANDIA  for  more  information.  [Klarer,  2001] 

Fuel  cells  produced  by  Ball  Aerospace  [Ball]  were  examined  by  SSC  -San  Diego  for  use 
on  the  MPRS  platform,  configured  as  the  URBOT. 

The  fuel  cells  were  powered  from  a  small  high-pressure  hydrogen  tank,  drawing 
oxygen  from  the  atmosphere.  We  used  the  50W  version  to  power  the  motors  of  the 
Urbot.  Because  of  noise  from  the  motors,  the  electronics  are  powered  by  a  separate 
battery.  The  Urbot  ran  fine  with  the  fuel  cell  (maybe  even  a  little  better  than  off  the 
battery).  The  energy  density  of  the  fuel  cell  itself  isn't  quite  high  enough  yet  - 1  think 
we  need  approximately  a  200 W  burst  to  climb  over  obstacles.  The  100W  version 
they  had  would  have  taken  up  more  than  a  third  of  the  payload  compartment  without 
the  fuel.  As  an  alternative,  we  could  use  batteries  to  directly  power  the  motors  and 
use  the  fuel  cell  to  power  the  electronics  and  to  charge  the  motor  batteries  whenever 
the  robot  was  stationary,  similar  in  concept  to  the  hybrid  power  systems  on  the  new 
gas-electric  cars.  However,  this  would  take  some  relatively  sophisticated  (and  space 
consuming)  electronics  to  manage  all  power  switching  and  battery  charging.  The 
current  fuel  types  aren't  particularly  dense  (energy  wise)  and  could  pose  a  significant 
risk  on  the  battlefield.  Use  of  the  methane  fuel  system,  now  under  development,  may 
improve  power  density.  This  technology  has  potential  but  needs  to  be  developed 
further  before  it  will  be  mature  enough  to  implement  on  the  MPRS.  [Bruch,  2001] 

Think  power  management.  Lots  of  times  we  have  developed  systems  and  not 
considered  battery  management  like  we  should  have.  Power  management  also  needs 
to  be  an  integral  part  of  the  system  engineering  process.  [Anderson,  2001] 

The  importance  of  energy  reserve  for  a  mobile  agent  cannot  be  overstated.  For  the  UGV 
community,  there  have  been  few  options.  The  UUV  environment  is  even  more  constrained. 
The  problem  can  be  approached  essentially  in  three  ways: 

■  Increase  energy  capacity. 

■  Decrease  energy  demands. 

■  Increase  energy  availability. 

System  designs  should  endeavor  to  optimize  at  least  two  of  the  three  approaches. 
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4.3.4  More  Technical  Challenges 

Challenges  are  real-time  processing  and  scalability.  [Sukhatme,  2001] 

Challenges  are  soldier/machine  interface,  machine  perception,  and  intelligent  control. 

[Bornstein,  2001] 

■S  A  most  salient  problem  is  real-time  resource  allocation,  or  dynamic  mission 
planning 

■S  must  be  able  to  rearrange  plans  during  operation 
■S  the  problems  scale  badly,  they  are  combinatorial 

V  each  instance  requires  a  unique  solution 

V  the  whole  problem  is  NP  complete 

V  worst  case  complexity  is  exponential  [Sztipanovits,  2001] 

In  addressing  the  problem  of  dynamic  mission  planning,  hierarchical  control  will 
always  be  required.  [Sztipanovits,  2001] 

Challenges  are  command  and  control,  sensors,  communications,  and  integration. 

[Van  Fosson,  2001] 

There  are  essentially  four  areas  in  UGV  development  that  cause  the  most  stress  on 
system  design:  mobility,  communication,  power,  and  navigation.  These  four  areas 
tend  to  trade  off  among  each  other.  For  instance,  better  navigation  capability 
generally  means  that  less  communication  is  required.  Larger  systems  have  better 
mobility,  but  require  more  power,  etc.  The  most  difficult  problem  for  UGV  systems 
regarding  mobility  is  negative  obstacle  detection  (holes).  The  shallow  look  angles 
tend  to  obscure  detection  using  visual  stereo  systems.  LIDAR  looks  to  be  a 
promising  technology  for  both  negative  obstacle  detection  and  probably  detection  of 
mines.  The  Demo  III  UGV  program  utilizes  a  LIDAR  system  in  a  "nodding"  mode  to 
provide  detailed  map  in  front  of  the  vehicle.  The  DEMO  III  navigation  algorithm 
then  uses  this  map,  along  with  visual  data  from  stereo  EO/IR  cameras  to  plan  a  route 
that  gives  the  vehicle  the  most  stable  path.  In  brown  water,  this  solution  may  not 
work.  Also,  in  VSW  the  UUV  may  have  to  deal  with  kelp.  Also,  an  essential 
element  of  a  robot  that  runs  the  risk  of  being  flipped  over  is  a  capability  to  right  itself, 
or  a  design  where  it  doesn't  matter  which  way  is  up.  This  design  could  simplify 
deployment  by  allowing  air  dropping  of  systems  into  the  target  location.  [Clemons, 
2001] 

From  the  MPRS  field  experience: 

The  primary  concern  to  the  users  was  the  fact  that  the  prototype  system  introduced 
new  batteries  into  what  is  an  already  immense  variety  of  batteries  that  have  to  be 
carried  into  the  field.  The  user  community  may  benefit  from  agreeing  upon  a  standard 
family  of  high-density  battery  configurations.  Other  user  requests  were  night  vision 
capability  and  a  lethal  robot  response  capability.  [Bruch  et  al.,  2000] 

The  current  goals  and  challenges  listed  in  the  descriptions  of  major  DoD  robotics 
programs  is  instructive  for  the  evident  Lessons  Learned.  These  goals  and  challenges 
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represent  perceived  disparities  between  operational  requirements  and  technological 
capabilities. 

4.3.4.1  Challenges  Motivating  the  DARPA  SDR  Program 


Goals  and  challenges  of  the  DARPA  SDR  program  include  the  following: 

S  A  large  collection  of  micro-robots  that  can  move,  communicate,  and  work 
collectively  to  achieve  a  collective  goal. 

S  Human  robot  interface  technologies  that  will  permit  the  human  to  interact  with  the 
robots  as  a  group  (including  the  capacity  to  task  and  query),  rather  than  requiring  the 
human  operator  to  interact  with  each  and  every  individual  robot. 

■S  Develop  the  software  needed  to  enable  the  cooperative  behavior  of  large  numbers  of 
micro-robots  to  accomplish  collective  tasks. 

■S  Develop  the  software  technologies  necessary  to  enable  inter-robot  communications  to 
support  collective  behaviors. 

S  Develop  computational  strategies  that  are  compatible  with  a  highly  resource 
constrained  environment. 

S  Develop  human  interface  strategies  that  support  both  tasking  and  query  of  the  micro¬ 
robot  collective. 

S  Perform  experiments  to  reliably  assess  the  progress  toward  developing  the  missing 
software  needed  for  the  successful  operation  of  large  numbers  of  micro-robots. 

[Gage,  2001] 

Inferences  we  may  make  from  the  above  listed  challenges  include  the  following: 

■  It  is  difficult  to  coordinate  many  small  vehicles. 

■  It  is  difficult  to  scale  control  strategies  to  very  large  numbers  of  vehicles. 

■  It  is  difficult  to  provide  useful  behavior  through  cooperative  action. 

■  It  is  difficult  to  coordinate  multiple  robots  by  multiple  operators. 

■  It  is  difficult  to  communicate  among  co-specifics  and  among  operators  due  to,  among 
other  causes,  problems  with  bandwidth. 

From  our  earlier  reports  on  the  underwater  environment,  we  must  anticipate  that  most  of 
the  SDR  program  challenges  will  be  even  greater  when  the  agents  are  operating  as  UUVs. 

4.3.4.2  Challenges  Motivating  the  DARPA  MARS  Program 

Similarly  the  goals  and  challenges  for  the  DARPA  MARS  program  are  as  follows: 

Develop  the  software  needed  to  synthesize  the  desirable  features  and 
capabilities  of  both  deliberative  and  reactive  control  while  incorporating  a 
capacity  for  learning.  This  solution  must  include  developing  the  theory  and 
technology  for  integrating  sensory  perception,  processing  and  representations 
into  a  single  control  architecture. 

•S  Develop  the  theory  and  technology  necessary  to  benefit  from  learning  as  a 
means  of  composing  and  refining  control  software  for  autonomous  mobile 
systems. 
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•S  Develop  the  theory  and  technology  for  symbiotic  sensor  interaction  needed  to 
enhance  the  perception  and  support  the  reasoning  required  for  the  real-time 
control  of  an  autonomous  mobile  robot  in  a  complex,  dynamic,  unstructured 
environment. 

Develop  a  uniform  set  of  evaluation  criteria  needed  to  evaluate  the  autonomy 
quotient  (AQ)  of  an  autonomous  mobile  robot. 

■S  Perform  field  experiments  and  demonstrations  to  reliably  assess  the  progress 
toward  developing  the  missing  software  needed  for  the  successful  operation 
of  mobile  autonomous  robots. 

■S  A  software  solution  framework  that  enables  autonomous  robots  to  synthesize 
the  desirable  features  and  capabilities  of  both  deliberative  (symbol-mediated) 
and  reactive  (sensor-mediated)  control,  while  incorporating  a  capability  for 
learning. 

A  software  composition  methodology  that  incorporates  both  programming 
(hand  coding)  and  learning-derived  (automated  coding)  software  composition 
to  increase  the  ability  of  autonomous  robots  to  function  in  unpredictable 
environments. 

S  Context  driven,  multi-sensor  processing  to  disambiguate  sensor-derived, 
environmental  state  information.  This  capability  has  the  potential  to  empower 
the  robot  to  accurately  characterize  the  environment,  and  hence  potentially 
exceed  the  performance  of  a  human  operator. 

■S  Metrics  and  benchmarks  to  assess  and  quantify  mobile  robot  autonomy. 

The  inferences  we  may  draw  from  this  second  list  are  as  follows: 

■  Roboticists  do  not  yet  know  how  to  get  their  products  to  operate  in  unpredictable 
environments. 

■  Programming  appropriate  responses  to  novel  tasks  and  environments  is  very  costly 
and  impracticable  for  the  MCM  mission. 

■  Roboticists  do  not  yet  know  how  to  create  an  efficient  and  successful  learning 
machine. 

4.3.4.3  Challenges  Motivating  the  DARPA  TMR  Program 

The  DARPA  TMR  challenges  are  as  follows: 

■S  Adequate  power  (energy); 

■S  Adequate  perception  for  obstacle  avoidance,  navigation,  mission 
requirements; 

■S  Adequate  communications  to  be  useful  to  the  soldier/operator; 

S  Adequate  processing  power; 

•S  Adequate  (effective  and  efficient)  operator  interface; 

S  Adequate  mobility.  [Gage,  2000] 

The  inference  we  may  draw  from  the  TMR  list  is  as  follows: 

■  Small  untethered  ground  robots  are  not  ready  for  tactical  operations. 
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4.3.4.4  Challenges  Motivating  the  Demo  III  Bravo  Test 

The  reported  Demo  III- Alpha  deficiencies  were  as  follows: 

■S  Target  scans  were  performed  vehicle-relative,  operators  could  not  make  the  necessary 
geolocation  transformations. 

V  Vehicle  had  no  terrain  elevation  data. 

V  Could  not  establish  a  correspondence  between  scan  results  and  the  terrain  map  at  the 
OCU. 

V  No  way  to  adjust  the  resolution  of  the  RSTA  sensors. 

V  No  ATR-on-the-move  capability. 

V  Algorithms  suffered  from  a  high  rate  of  false  alarms. 

V  No  range  information  for  ATR. 

V  No  AGC  for  the  FLIR. 

V  Detection  algorithms  were  performed  serially,  wasting  time  and  resources. 

V  Communications  suffered  delays  and  dropouts.  [Bonner,  2001] 

And  from  another  opinion  of  Demo  III  challenges: 

V  Major  problem  is  autonomy  -  involving  perception  for  mobility;  specifically  for 
obstacle  avoidance  of  both  positive  and  negative  obstacles 

V  As  this  had  occupied  most  of  the  developers'  attentions,  not  a  lot  of  time  and 
resources  are  being  spent  on  the  RSTA  mission  [Haug,  2001] 

The  inference  we  may  draw  from  the  Demo  III  list  are  as  follows: 

■  Large  semiautomatic  ground  robots  are  not  ready  for  tactical  operations. 

4.3.4.5  Challenges  Anticipated  by  the  Army's  FCS  Program 

The  expected  challenges  to  the  Army's  Future  Combat  Systems  objectives: 

V  Autonomous  (unsupervised)  mobility; 

V  Tactically  intelligent  behaviors; 

V  Robust  adaptive  perceptual  capabilities; 

V  Intelligent,  adaptive  vehicle  behaviors; 

V  Modular,  non-intrusive  soldier-robot  interface; 

V  Schedule  -  the  above  three  deficiencies  to  be  addressed  in  the  FCS  STO  from 
2000  to  2005.  [Bornstein  et  al.,  2001] 

The  inferences  that  we  may  draw  from  the  above  list  are  as  follows: 

■  FCS  has  not  considered  the  necessity  of  evolution. 

■  The  ambition  of  FCS  is  comparable  to  the  creation  of  man  from  the  Euphrates  mud. 

4.3.4.6  Summary  of  the  UGV  Technology/Capability  Shortfalls 

V  Critical  non-robot-specific  component  technologies: 

V  Power:  need  higher  energy  densities. 
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■S  Displays:  need  more  of  the  relevant  information,  need  to  discover  what  is 
relevant. 

■S  Communications:  need  greater  bandwidth,  unimpeded  though  the  medium  - 
greater  than,  but  at  least  equal  to  non-robotic  solutions  (i.e.  soldier  assigned). 

■S  Processing:  need  higher  MIPS  per  mass/volume/power. 

S  Sensors:  need  higher  resolution,  range;  lower  size,  weight,  power  draw. 

S  Localization:  need  the  equivalent  of  CP-DGPS  anywhere  w/  or  w/out  DGPS. 
[Gage,  2001] 

Critical  Robot  Capability  Needs: 

■S  Locomotion:  go  anywhere. 

■S  Perception:  recognition  of  obstacles,  landmarks,  threats,  friends. 

■S  Detection,  classification,  identification,  localization,  and  tracking  of  targets. 

•S  Sensor  guided  mobility. 

S  Being  small  enough  and  big  enough. 

■S  Implementation:  fitting  in  rucksack  envelope. 

S  Achieving  functionality,  performance. 

•S  Supervised  autonomous  navigation. 

■S  How  operator  tasks,  monitors,  overrides. 

•S  How  robots  actually  execute  moves. 

•S  Implementation:  making  it  all  actually  work. 

■S  Robotic  system  decomposition/architecture(s).  [Gage,  2001] 

Key  technologies  and  issues: 

■S  Communications  -  [greater  than  manned  solutions,  if  man  remains  in  the  loop]. 

■S  Power  -  [equivalent  to  manned  solutions]. 

■S  Perception  and  mobility. 

■S  Modularity:  minimizes  duplication  of  sensor  and  processing  resources,  improves 
sensor  fusion  for  alarms  and  alerts. 

■S  Interoperability:  for  mechanical,  power,  and  messaging. 

■S  Integration  and  implementation:  [however]  there  is  a  tension  between  integration 
flexibility  (modularity)  and  tight  subsystem  coupling.  [Gage,  2000] 

But  our  greatest  operational/programmatic/technology  shortfall  is  that  we  have  not  yet 
been  able  to  (1)  define  a  useful  task  for  a  robot,  and  (2)  get  that  robot  to  perform  its  defined 
task  reliably  and  repeatedly  on  its  own  in  any  unpredictable  real-word  environment.  Thus, 
we  have  a  very  tenuous  foundation  from  which  to  proceed  to  more  complex  capabilities. 

4.3.5  Addressing  the  Challenges 

4.3.5.1  Use  of  a  Joint  Architecture  for  all  Unmanned  Ground  Systems 

Generally,  it  is  recognized  that  commonality  saves  time  and  money.  The  reuse  of 
developed  components  is  economical.  The  adherence  to  information  exchange  standards 
saves  the  labor  of  translation. 

The  U.S.  Army  Tank- Automotive  &  Armaments  Command  UGV  soldier-machine- 
interface  may  be  of  value  to  UUV  applications.  Useful  also  are  the  hierarchical 
software  architecture  (4D/RCS)  and  JAUGS  communication  protocols  developed  by 
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NIST  and  the  Joint  Robotics  Program  Office,  respectively.  We  also  find  a  lot  of 
value  at  TARDEC-Vetronics  in  utilizing  software  APIs  in  increase  re-use  of  software 
developed.  [Brendle,  2001] 

Joint  Architecture  for  Unmanned  Ground  Systems  (JAUGS): 

S  objective  to  ensure  interoperability  of  future  unmanned  ground  systems 

S  use  will  be  mandatory  on  all  JRP  systems 

•S  ref:  http://www.iointrobotics.com/Jaugs/  [Gage,  2000] 

There  is  a  risk  to  the  imposition  of  standards  and  the  reuse  of  components  and 
architectures  that  are  sub-optimal,  however.  The  risk  is  the  perpetuation  of  inefficiencies  and 
the  inhibition  of  the  development  of  better  solutions.  Yet  any  of  the  factors  that  determine  the 
optimality  of  solutions,  including  cost,  interoperability,  extensibility,  and  efficiency,  may  be 
traded  in  the  standardization  process. 

One  category  of  standardization  rules  might  guide  the  evolution  of  information  exchange 
formats  so  that  the  degree  of  compatibility  among  component  versions  exists  at  least  as  long 
as  the  components  remain  in  general  use.  After  all,  standards  like  dictionaries  only  represent 
the  habits  within  the  participating  population — habits  that  have  their  own  good  and  common 
reasons  for  adoption  and  persistence. 

4.3.5.2  Addressing  the  Challenges  of  System  Integration 

In  addition  to  the  Lessons  Learned  from  the  MDARS  program  that  we  mentioned  at  the 
beginning  of  this  Section,  the  DARP A/Army  Demo  programs,  used  to  quickly  integrate 
various  technologies  and  demonstrate  their  utility  in  a  tactical  unmanned  vehicle  RSTA 
scenario,  provided  many  good  lessons  in  systems  engineering.  Some  examples  include  the 
following: 

A  complex  system  integration  effort  requires  a  well  functioning  IPT.  [Glass,  2001] 

Integrators  must  pay  close  attention  to  the  component  experts.  [Gothard  et  al.,  2001] 

It  is  critical  to  have  an  up-to-date  interface  control  document  (ICD)  to  facilitate  the 
integration  of  components  provided  by  different  sources.  [Glass,  2001] 

Complete  descriptions  of  interfaces  are  required  for  both  software  and  hardware 
integration  [Gothard  et  al.,  1993] 

Make  sure  that  the  component  developers  comply  with  the  software  interface 
standards.  Otherwise,  fixing  interfaces  may  consume  as  much  time  as  writing  the 
component  code.  [Gothard  et  al.,  2001] 

The  integrating  authority  should  provide  a  development  and  debugging  environment 
for  the  developers.  A  good  simulation  of  the  vehicle  would  have  been  useful  for 
independent  developers.  [Glass,  2001] 

The  ability  to  record  and  to  playback  real  or  simulated  data  assists  system  checkout 

[Gothard  et  al.,  1993] 
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When  porting  software  one  needs  tools  and  test  cases  to  verify  a  successful  port 

[Gothard  et  al.,  1993] 

Do  not  depend  solely  on  manufacturers'  specifications  for  products.  Rather  the 
products  must  be  characterized  in  the  environment  in  which  they  will  be  used. 

[Gothard  et  al.,  1993] 

The  computing  hardware  and  operating  system  baselines  should  be  stable  before 
effort  is  expended  to  integrate  applications.  [Glass,  2001] 

When  developing  new  software,  make  sure  that  the  supporting  hardware  is  absolutely 
reliable.  Having  hardware  teams  on  standby  helped.  [Gothard  et  al.,  2001] 

Plan  alternatives  for  high-risk  items.  [Glass,  2001] 

Have  a  backup  plan  for  everything.  When  expecting  a  new  piece  of  hardware,  or  a 
new  software  solution  for  a  task,  keep  the  older  working  version  around  (including 
interfaces)  just  in  case  the  new  version  does  not  integrate  well  and  function  as 
planned,  or  does  not  arrive  in  time.  [Gothard  et  al.,  2001] 

Integrators  must  keep  exact  records  of  steps  taken  during  integration,  debugging,  and 
troubleshooting.  Changes  can  take  the  system  away  from  functionality,  and 
restoration  will  be  difficult  without  records  that  detail  the  working  states  that  were 
passed  through.  Records  of  failure  states  are  also  helpful  for  making  later  design 
improvements.  [Gothard  et  al.,  2001] 

Occasionally,  failure  states  turn  out  to  be  serendipitous  when  the  real  error  was  in  our 
expectation  of  how  the  system  should  work.  The  lesson  is  that  a  complex  system  can  be 
characterized  by  state  variables  or  parameters,  but  the  functionality  of  those  individual  states 
cannot  be  known  with  certainty  until  the  environment  in  which  the  function  must  be 
exercised  or  expressed  is  also  equally  characterized.  No  one  state  of  the  system  should  be 
expected  to  be  universally  useful. 

4.3.5.3  Golden  Rule  of  Evolutionary  Development 

When  debugging,  make  only  one  change  at  a  time.  [Gothard  et  al.,  2001] 

4.3.5.4  Making  Sense  out  of  an  Uncertain  World 

Active  perception  is  the  means  used  by  advanced  animals  to  make  sense  out  of  the 
uncertain  world.  Robots  can  be  programmed  without  too  much  difficulty  to  perform 
similarly.  Active  perception  begins  with  the  awareness  of  uncertainty.  A  behavioristic 
definition  of  uncertainty  is  the  inability  to  choose,  evidenced  by  an  inhibition  of  motion  when 
movement  would  ordinarily  be  expected  (from  the  observer's  perspective).  An  expectation 
emerges  to  overcome  the  inhibition.  An  expectation  may  be  defined  as  an  orienting  response 
to  the  location  of  a  previously  detected  environmental  feature.  The  particular  feature  selected 
depends  upon  the  prevailing  biases.  Should  the  feature  exist  at  that  location,  then  the 
expectation  is  confirmed,  at  which  point,  the  organism  improves  its  recognition.  The 
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successful  confirmation  evokes  a  second  expectation,  based  upon  previously  learned  sensor¬ 
sensor  and  sensor-motor  relationships,  that  lead  to  a  second  orienting  response,  and,  if 
confirmed  by  environmental  conditions,  further  improves  the  recognition.  Complex 
behaviors  can  be  rapidly  and  smoothly  executed  following  this  sequence.  However,  when  an 
expectation  is  not  confirmed,  the  level  of  uncertainty  is  increased,  the  sequence  is  interrupted, 
the  prevailing  biases  are  reset  (permitting  alternative  choices),  and  the  organism  is  forced  to 
start  over  with  a  new  expectation. 

Under  uncertainty,  it  is  necessary  to  create  hypotheses,  which  are  nothing  more  than 
complex  expectations.  Without  uncertainty,  no  hypotheses  would  be  created.  This  ability  to 
deal  with  uncertainty  permits  the  organism  to  expect  different  features  from  the  environment 
and  test  them  out  through  some  active  exploration.  Recognition,  certainty,  or  confidence 
validate  one's  hypothesis  with  the  sensor  data  that  were  actively  acquired  because  the 
hypothesis  was  created  and  the  required  features  were  present  within  the  environment.  Errors 
of  validation,  which  can  occur  when  some  of  the  inhibitory  neural  mechanisms  are 
dysfunctional,  are  called  hallucinations.  Dreams  are  hallucinations  as  the  process  runs  free 
without  the  benefit  of  environmental  feedback. 

Thus,  natural  vision  systems  accomplish  much  more  than  the  simple  extraction  of  features 
from  the  input  stream.  Put  another  way,  the  extraction  of  features  in  natural  systems  is  more 
involved  than  template  matching.  Natural  vision  is  a  component  of  a  larger  complex  of 
systems  that  meet  the  information  needs  of  the  organism.  The  natural  vision  system 
independently  acquires  information  to  achieve  the  organism's  objectives  under  uncertainty. 
Uncertainty  exists  because  the  environment  is  chaotic.  The  reduction  in  uncertainty  is 
accomplished  by  the  agent's  mobility  through  the  environment.  This  operation  increases 
uncertainty  for  a  third  party,  in  accordance  with  the  second  law  of  thermodynamics,  but 
decreases  uncertainty  for  the  agent.  Active  perception  is  a  form  of  mobility  where  the 
direction  of  movement  is  determined  by  an  interaction  of  expectation  and  results.  The  new 
information  is  used  to  resolve  the  uncertainty. 

The  integration  of  sensory  and  motor  capabilities  increases  the  local  computing  difficulty 
many  times  over  compared  to  an  application  that  uses  only  sensors  or  effectors, 
supplementing  the  missing  capabilities  with  human  cooperation.  The  difficulty  resides  in  the 
requirement  to  adjust  effector  output  as  sensor  input  changes,  and  in  the  consequences  on 
sensor  input  as  effector  output  changes.  Even  a  stable  world  can  produce  a  huge  variety  of 
appearances  as  an  agent  moves  through  it.  This  complexity  is,  of  course,  compounded 
because  the  world  is  also  dynamic  and  unpredictable,  full  of  surprises,  and  occupied  by  other 
actively  perceiving  agents. 

Biological  perception  is  active,  with  information  making  several  round-trips  between  the 
creation  of  expectations  and  their  validation  through  sensing  selected  environmental  features 
before  gross  higher  risk  behaviors  are  released  and  the  organism  commits  itself.  Active 
perception  with  the  consequent  buildup  of  certainty  (familiarity)  is  the  means  by  which 
natural  intelligence  deals  with  uncertainties  in  the  operational  environment.  The 
incorporation  of  active  perception  mechanisms  into  robot  control  algorithms  should  provide 
similar  advantages. 
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4.3.5.5  Use  of  Adaptation  or  Learning 

Programming  the  rules  that  permit  a  robot  to  operate  in  an  unstructured  (unconstrained) 
environment  is  very  difficult  and  has  been  the  unsuccessful  approach  of  Expert  Systems  in 
artificial  intelligence  (AI).  Therefore,  learning  algorithms  are  now  favored. 

Learning  algorithms  will  be  necessary  to  insure  robustness  and  the  ability  to  rapidly 
adapt  to  new  environments  and  conditions.  [Bornstein  et  al.,  2001] 

There  are  other  benefits  to  learning.  One  benefit  is  adaptation  to  component  failure — 
contributing  a  solution  to  our  requirement  for  fault  tolerance. 

A  notable  example  of  this  application  is  an  Air  Force  Office  of  Scientific  Research- 
sponsored  product  from  Barron  Associates,  Inc. 

They  report  that  their  self-designing  control  system  can  continuously  optimize 
performance  and  can  accommodate  events  such  as  failures,  anomalies,  and  damage, 
as  well  as  maximize  an  aircraft's  flight  envelope,  maneuverability,  and  changing 
mission  requirements.  It  could  provide  compensation  for  damaged  or  malfunctioning 
control  surfaces.  The  self-designing  controller  would  automatically  determine  the 
effects  of  a  collision,  equipment  failure,  mid-air  explosion,  ice  formation,  or  other 
event,  and  use  the  remaining  control  surfaces  to  adapt  to  these  effects  and  maintain 
safe  flight.  [Jacobs,  1996] 

While  roboticists  are  actively  experimenting  with  adaptive  algorithms  that  provide 
perceptual  capabilities  for  mobile  robots,  and  create  environmental  maps,  they  will 
sometimes  need  adaptive  algorithms  that  permit  the  robot  to  function  even  when  its  sensors 
or  effectors  have  been  damaged  or  misaligned. 

Is  this  form  of  adaptation  always  a  good  thing? 

The  MDARS-I  developers  noticed  that  a  well  implemented  adaptive  behavior  could 
mask  component  faults  such  as  a  problem  in  the  steering  mechanism  that  constantly 
"pulled  to  the  left".  [Gage,  2000] 

But,  can  we  fault  a  system  that  continues  to  perform  even  as  components  begin  to  fail? 

A  combination  of  adaptive  compensation  and  fault  detection  and  reporting  would  be 
desired  to  ensure  graceful  degradation  without  masking  the  evolving  failure. 

[Everett,  2001] 

Indeed,  nature  employs  such  mechanisms  to  permit  the  preservation  of  most  functional 
capabilities  under  conditions  of  injury  and  aging.  The  existence  of  considerable  reserve, 
redundancy,  and  reallocation  ability  facilitates  these  mechanisms,  while  the  ubiquitous 
distribution  of  pain  fibers  provides  for  the  early  warning  of  conditions  internal  and  external  to 
the  organism  to  which  it  should  take  some  prophylactic  or  defensive  action. 
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A  robot  must  also  adapt  to  the  new  task  objectives,  and  to  short-  and  long-term  changes  in 
its  capabilities,  and  in  the  demands  of  the  workspace.  Autonomous  work  systems  must 
therefore  have  the  capacity  for  continuous  learning  and  adaptation. 

Old  learning  should  facilitate  new  learning.  The  hope  of  every  teacher  is  that  with  each 
new  lesson,  learning  is  a  little  easier  than  the  last.  Building  on  previous  knowledge  makes 
new  learning  possible.,  Allowing  previous  knowledge  to  bias  new  responses  makes  new 
learning  possible.  A  robot  should  not  have  to  be  re-taught  the  use  of  a  wrench  or  the  purpose 
of  nuts  and  bolts  for  each  new  assembly  project. 

Training  time  in  natural  adaptive  systems  is  proportional  to  task  complexity.  We  should 
anticipate  that  as  task  requirements  increase,  so  should  the  cost  of  training  an  autonomous 
work  system  in  preparation  for  task  performance.  Systems  must  be  engineered  to  minimize 
this  cost.  Thus,  learning  should  be  preserved  so  that  generalizations  to  new  tasks  become 
possible. 

The  development  of  learning  algorithms  for  robotics  applications  could  benefit  from  a 
clearer  understanding  of  learning  theory  from  the  neuropsychological  literature. 
Unfortunately,  the  AI  community  that  supports  robotics  development  has  ignored  this 
literature.  The  problem  of  reliability  or  certainty  in  control  may  explain  this  oversight. 

Robots  are  still  thought  of  as  machines,  of  which  the  performance  must  be  absolutely 
predictable.  Learning,  in  the  biological  context,  introduces  an  element  of  uncertainty  that  has 
been  at  best  a  nuisance  in  robotics  applications. 

Biological  systems  are  also  machines,  and  more  importantly,  they  are  machines  that  make 
errors.  Learning  and  adaptation  permit  biological  machines  to  recover  from  errors,  and  in 
some  cases,  to  discover  the  benefits  of  making  what  was  previously  an  error,  but  after 
learning,  becomes  a  more  successful  response. 

4.3.5.6  Redefining  Machine  Intelligence  Requirements 

A  problem  with  the  development  of  machine  intelligence  is  that  humans  (robotics 
developers)  do  not  understand  their  own  cognitive  mechanisms.  This  lack  of  understanding 
would  not  be  a  problem  if  the  developers  did  not  attempt  to  recreate  strictly  human 
capabilities.  For  example,  humans  use  maps  to  maintain  their  orientation  with  respect  to  fixed 
features  in  the  environment.  Robot  developers  assume  that  this  type  of  orientation  is  also 
required  for  a  robot  and,  therefore,  the  robot  must  have  a  map  or  create  a  map  from  the 
integration  of  its  sensor  experiences.  An  alternative  approach  might  be  to  ask  what 
information  the  robot  must  have  to  accomplish  the  task  assigned  by  the  human  operator.  The 
laying  down  and  subsequent  retracing  of  trails  is  one  possible  substitute  for  a  map. 

Approaches  taken  by  the  developers  of  the  TMR  and  Demo  programs  to  meet  the  many 
challenges  listed  above  show  the  common  human-centricity  of  the  development  process. 
These  approaches  consciously  or  unconsciously  interpose  between  all  sensor  information¬ 
processing  algorithms  and  all  execution  commands  for  navigation  and  target  acquisition  the 
requirement  to  make  the  information  intelligible  to  a  human  observer.  Because  of  this 
requirement,  the  common  approach  to  machine  recognition  involved  template  matching  of  an 
image  that  was  first  identifiable  to  the  human  operator. 


81 


Similarly,  obstacle  avoidance  involved  terrain  characterization  of  environmental  elements 
(scene  components)  into  broad  classes  (such  as  soil,  green  vegetation,  rocks,  and  man-made 
obstacles)  that  were  assumed  by  the  developers  to  have  an  impact  upon  the  mobility  or 
operation  of  an  autonomous  system.  They  do  have  an  impact  upon  the  mobility  of  a  human 
organism,  and  upon  the  mobility  of  vehicles  driven  by  humans  such  as  HMMWVs,  but  it 
might  be  imposing  an  unnecessary  constraint  upon  the  information  processing  necessary  for 
some  other  type  of  autonomous  agent  to  first  view  the  scene  and  the  problems  of  mobility 
through  the  perceptual  requirements  of  a  human.  Does  the  bull  in  the  proverbial  china  shop 
care  if  the  shelves  are  loaded  with  delicate  porcelain?  Probably  not,  the  bull  no  doubt  only 
cares  that  the  obstacles  are  negotiable  in  his  objective  to  exit  the  shop.  Knowing  the  nature  of 
bulls,  we  do  not  generally  place  them  in  china  shops,  but  we  do  find  other  good  uses  for 
them. 

Taking  a  lesson  from  this  example,  to  develop  a  successful  and  useful  autonomous 
underwater  vehicle,  we  may  not  require  the  onboard  information-processing  algorithms  to 
comply  with  our  perceptual  and  decision-making  needs.  Instead,  and  more  simply,  we  could 
determine  the  full  scope  of  information  available  in  the  task  environment,  and  the 
impediments  and  assistances  available  in  that  same  environment.  Then  we  could  define  the 
behavioral  objectives  appropriate  for  a  AUV,  given  an  available  set  of  sensor  and  motor 
capabilities,  and  then  work  out  the  necessary  information-processing  steps  that  most 
efficiently  achieve  the  required  behaviors  with  the  available  equipment  under  the  particular 
task  circumstances  and  task  objectives. 

4.3.5.7  Redefining  Machine  Autonomy 

4.3.5.7.1  Defining  Autonomy 

What  is  autonomy?  Are  people  autonomous?  Are  dolphins?  Are  dogs?  Can  a  machine  be 
autonomous?  How  is  an  autonomous  machine  supposed  to  behave?  We  can  probably 
approach  these  questions  from  several  different  perspectives,  but  we  are  interested  here  in 
understanding  the  mechanisms  of  autonomy  so  that  we  can  emulate  these  mechanisms  in  a 
robot.  Therefore,  we  ask  what  an  organism  is  doing  when  it  demonstrates  autonomy. 

For  man,  autonomy  is  customarily  considered  to  be  a  result  of  free  choice.  Webster's 

Dictionary  defines  autonomy  as  the  quality  or  state  of  being  self-governing.  An 
autonomous  person  is  one  who  is  allowed  to  act  on  his/her  choices.  A  dog,  on  the  other  hand, 
is  generally  not  given  this  liberty,  perhaps  for  the  reason  that  the  dog  is  not  considered  to 
have  the  capacity  for  free  choice.  However,  those  who  have  attempted  to  maintain  control 
may  be  forced  to  concede  that  the  dog  indeed  exercises  free  choice.  A  dog  does  what  it  likes, 
and  those  who  wish  to  control  a  dog  find  that  their  success  is  greater  if  they  can  couple  their 
desired  result  with  something  that  the  dog  likes  to  do. 

But  why  stop  with  the  dog?  Is  a  bird  autonomous?  How  about  a  frog,  a  fish,  a  lobster,  or  a 
roundworm?  On  close  inspection,  all  of  these  species  seem  to  have  choices,  and  often  make 
the  right  choice  for  their  circumstances.  They  find  the  proper  food,  the  proper  mates,  avoid 
predators,  and  survive.  Therefore,  we  have  equated  autonomy  with  survival. 

Even  a  single-celled  protozoan  survives  without  outside  control.  First  of  all,  the  protozoa 
exist  in  large  numbers.  The  loss  of  any  one  or  even  many  of  them  does  not  immediately 
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threaten  the  survival  of  the  species.  Even  so,  each  protozoan  has  built,  within  its  cellular 
apparatus,  mechanisms  to  preserve  its  integrity.  These  mechanisms  allow  it  also  to  recognize 
and  acquire  food,  avoid  predators  and  poisons,  and  find  co-specifics  for  copulation.  Since  the 
protozoan  is  unicellular,  its  behavioral  mechanisms  must  function  at  sub-cellular  levels. 
Protozoan  mouths,  swimmers,  eyespots,  and  chemosensors  are  all  elaborated  from  the  cell 
membrane — an  organism  in  detail  within  a  single  cell !  This  differentiation  of  the  cell 
structure  contributes  to  variety  in  function,  and  variety  in  function  to  survival. 

We  can  reduce  the  causal  chain  of  autonomy  mechanisms  even  further  to  the  properties  of 
DNA,  as  can  be  done  with  all  vital  mechanisms.  We  might  venture  to  propose  that  autonomy 
is  a  fundamental  property  of  DNA.  The  ability  of  DNA  to  manufacture  proteins  or  enzymes, 
and  regulate  their  action,  must  subserve  all  autonomy  as  these  are  the  substrates  of  the 
cytoplasm  and  the  differentiation  of  cellular  components  that  lead  to  specific  sensitivities  to 
the  environment,  and  to  the  reactive  capacity  of  the  cell. 

What  does  the  DNA  molecule  do  to  promote  its  own  survival  and  replicate  itself?  The 
replication  of  DNA  is  well  known.  Under  the  circumstances  in  which  most  DNA  is  usually 
found,  that  is,  protected  within  the  cytoplasm  of  a  cell,  the  DNA,  through  its  control  over  the 
architecture  and  function  of  the  cell,  directly  attempts  to  preserve  itself.  Yet,  even  outside  a 
cell,  the  DNA  survives.  The  simplest  configuration  in  which  DNA  is  found  is  the  virus.  The 
viral  DNA  manages  a  protective  coat  of  protein  before  it  leaves  its  host  cell. 

The  DNA  molecule  also  can  exemplify  the  mechanisms  of  autonomy.  Each  nucleotide  on 
the  DNA  strand  is  a  receptor  for  another  specific  nucleotide  on  another  DNA  strand  or  on  a 
mRNA  strand.  Once  the  sites  on  a  strand  are  all  occupied,  the  molecule  unzips  and  it  is  ready 
for  replication.  The  DNA,  through  mRNA  and  tRNA  also  determine  the  selection  and 
sequencing  of  specific  amino  acids  from  the  intracellular  environment  to  assemble  proteins. 
Some  proteins  hang  around  the  DNA  and  act  as  enzymes.  Molecular  forces,  intrinsic  to  the 
DNA  and  to  enzymes  that  it  produces,  regulate  this  process  and  subserve  the  binding  and 
unbinding  of  different  connections  that  rebuild  the  molecule  and  then  split  it  apart  to  repeat 
the  process.  The  availability  of  critical  amino  acids  limits  the  rate  of  this  process.  Thus,  the 
DNA  and  mRNA  strands  can  be  viewed  as  a  sequence  of  receptors  that  wait  for  the 
occurrence  of  a  particular  environmental  event  ( the  presence  of  a  tRNA  molecule  with  a 
bound  amino  acid).  Yet  the  DNA  also  causes  events  to  occur  that  increase  the  probability  that 
critical  amino  acids  will  become  available  to  it.  The  power  that  the  DNA  molecule  has  to 
control  its  environment  is  exercised  again  through  the  production  of  proteins.  The  completed 
protein,  by  virtue  of  its  specific  conformation,  moves  off  the  mitochondrial  factory  to  become 
incorporated  into  the  cellular  architecture  or  act  as  an  enzyme  to  further  affect  some  cellular 
process.  The  DNA  is  thus  capable  of  regulating  cellular  function  according  to  its 
requirements  for  survival  and  replication. 

The  essential  elements  of  an  autonomous  mechanism  are  all  present  in  processes 
controlled  by  or  intrinsic  to  the  DNA,  and  all  contribute  to  the  persistence  (survival)  and 
replication  of  the  DNA.  These  essential  elements  are  as  follows: 

■  Intrinsic  physical  forces  that  attract  or  repel  components  (motive  forces). 

■  Receptors  sensitive  to  specific  environmental  conditions  (discrimination  or 
selectivity). 
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■  Mechanisms  to  limit  the  environmental  effects  on  the  conformation  or  composition  of 
the  agent  (encapsulation). 

■  Mechanisms  to  alter  the  physical  relationship  of  the  agent  to  its  environment 
(mobility). 

An  autonomous  system  survives.  Whatever  promotes  survival  thus  determines  autonomy. 
This  definition  of  autonomy  is  consistent  with  the  biological  perspective  that  autonomy  is  a 
requisite  for  survival,  for  survival  is  synonymous  with  the  ability  to  act  again.  In  a  single- 
celled  organism,  the  differentiation  of  the  cell  membrane  promotes  survival  by  forming  a 
connection  between  an  environmentally  sensitive  region  and  an  effector  region  that  moves 
the  cell  relative  to  the  environmental  stimulus.  This  connection  has  the  qualities  of  a  reflex.  A 
reflex,  however,  is  not  what  is  customarily  thought  of  as  a  certain  and  invariant  reaction 
given  the  proper  trigger  conditions.  Rather,  the  reflex  is  a  non-linear  response  to  a  trigger 
stimulus  that  is  much  modulated  by  the  internal  conditions  of  the  organism.  The  reflex 
response  is  calculated  to  maintain  the  optimal  internal  state  of  the  organism,  thus  promoting 
survival  under  the  prevailing  environmental  (stimulus)  conditions. 

The  protozoan  lives  by  its  reflexes,  envaginating  nutrients,  avoiding  toxins,  and 
occasionally  communicating  nuclear  information  with  friends.  Without  risk  of  over 
generalizing,  the  role  of  these  reflexes  may  be  extended  to  all  living  organisms,  including 
man.  In  multicellular  organisms  such  as  man,  reflexes  subserve  all  behavior.  To  get  a  rich 
variety  of  behaviors,  one  must  evoke  and  modulate  many  reflexes.  Natural  controllers 
(brains)  control  by  virtue  of  their  ability  to  evoke  and  modulate  the  reflexes.  All  natural 
behavior  is  accomplished  through  the  evocation  and  modulation  of  reflexes.  All  high-level 
adaptive  behavior  is  accomplished  through  the  conditioning  of  these  reflexes,  which  are 
always  coupled  to  environmental  conditions. 

Natural  selection  has  ensured  that  most  reflexes  are  very  useful,  meaning  that  the  stimulus 
categories  are  quite  relevant,  so  the  responses  achieve  reliable  and  beneficial  results.  We  use 
reflexes  to  orient  to  biologically  significant  events.  We  also  use  reflexes  to  avoid  other 
biologically  significant  events.  Without  these  reflexes  we  would  not  survive  long,  and  there 
goes  our  autonomy.  If  our  reflexes  are  well  designed,  all  of  our  responses  will  be  appropriate 
in  the  sense  that  they  promote  our  survival.  Problems  do  come  up  when  the  survival  of 
different  individuals  conflict,  or  when  the  environmental  conditions  change  beyond  the  limits 
in  which  the  fundamental  reflexes  were  designed  to  operate.  In  the  former  case,  one  of  the 
two  individuals  may  disappear.  In  the  latter  case,  an  entire  species  may  become  extinct,  but 
fortunately  for  us,  there  is  more  to  the  reflex  story.  Higher-level  processes  permit  the 
organism  to  use  its  reflexes  to  effect  the  necessary  changes  in  the  environment  that  restore 
the  viable  conditions. 

Before  we  continue  the  story,  it  might  be  useful  to  contrast  an  automatic  process  (that  is 
the  common  perception  of  a  reflex)  with  an  autonomous  process  (that  is  subserved  by 
biological  reflexes).  An  automatic  process  executes  an  action  without  a  second-order 
modulator.  External  or  internal  events,  with  respect  to  the  host  system,  may  trigger,  generate, 
or  regulate  an  automatic  process,  but  do  so  without  regard  to  the  consequences  upon  the  host. 
The  thermostatic  control  of  a  heater  is  one  example.  While  the  process  could  maintain  a 
reasonably  constant  temperature  in  the  medium  connected  to  the  thermostat,  the  process  is 
inflexible  with  regard  to  the  set-point  of  the  temperature,  which  must  be  adjusted  by  some 
other  means  (a  human  operator?). 
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A  different  example  of  an  automatic  process  is  a  wind-up  toy.  The  tension  on  the  wound 
spring  of  the  toy  acts  as  internal  trigger  and  driver  (source  of  energy)  to  activate  levers  and 
turn  gears  that  animate  the  toy.  The  mechanical  links  to  the  external  environment  are  strictly 
deterministic  and  yield  a  fixed  behavior  until  the  spring  loses  its  tension.  Typical  wind-up 
toys  do  not  have  sensors  of  the  external  environment  to  modulate  the  links  between  spring 
and  mechanical  effectors,  thus  they  are  likely  to  bump  into  obstacles  and  fall  off  ledges. 
These  two  examples  demonstrate  the  inadequacies  of  automatic  processes.  In  the  first 
example,  the  automatic  process  was  deterministically  dependent  upon  the  conditions  in  the 
external  environment,  while  in  the  second  example,  the  automatic  process  was 
deterministically  dependent  upon  conditions  in  the  internal  environment. 

An  autonomous  system  is  necessarily  built  with  automatic  elements,  that  is,  with 
receptors,  sources  of  motive  energy,  and  mechanical  effectors.  In  addition  to  these,  the 
autonomous  system  has  sensors  for  the  internal  and  the  external  environments  that  provide 
information  used  to  modulate  the  automatic  processes.  While  the  automatic  process  responds 
unidimensionally  to  either  internal  or  external  factors,  the  autonomous  process  integrates 
internal  and  external  factors  in  the  response  decision.  An  example  of  an  autonomous  process 
is  the  patellar  tendon  reflex  in  a  biological  system.  Muscle  tension  is  maintained  by  internal 
factors  (primarily  spinal  and  cortical  influences  on  the  motor  neuron)  but  modulated  by  the 
change  in  the  stretch  on  the  tendon  brought  about  by  an  external  load  on  the  limb  that 
changes  the  joint  position  and  stretches  the  muscle.  The  reflex  counters  the  changes  in  joint 
position  by  activating  an  opposing  muscle  group.  The  ideal  position  for  the  system  is  at  the 
center  of  its  response  curve,  the  point  of  maximum  slope.  The  reflex  to  restore  the  system  to 
the  ideal  position  opposes  perturbations  from  the  environment. 

The  advantage  of  an  autonomous  process  over  an  automatic  process  is  that  action  in  the 
former  leads  to  an  improved  status  of  the  system  in  relationship  to  the  environment  and  thus 
to  a  reduction  in  the  required  intensity  of  subsequent  action.  The  action  of  an  autonomous 
system  is  dependent  upon  internal  and  external  factors.  The  autonomous  system,  by  being 
self-governing,  optimizes  its  own  position  with  respect  to  what  is  possible.  Furthermore,  the 
extension  of  the  basic  mechanisms  of  autonomy  with  long-term  adaptation  allows  an 
advanced  system  to  predict  changes  in  the  environment  and  act  in  anticipation  of 
environmental  events,  thus  freeing  the  system  from  a  strictly  reactive  mode  of  operation. 
(Short-term  adaptation  of  reflexes  does  occur  at  the  level  of  the  spinal  cord,  but  long-term 
adaptation  (learning)  does  not  occur  there.  Learning  requires  an  association  ganglion  (brain), 
but  even  round  worms  have  them.) 

4.3.5.7.2  Requirements  for  Autonomous  Behavior 

We  now  return  to  our  statement  that  reflexes  afford  changes  in  the  external  environment. 

When  the  external  environment  changes,  the  potential  for  information  increases.  In  the 
simplest  sense,  autonomy  is  evident  in  an  agent's  ability  to  act  on  information  that  has 
become  available  as  a  consequence  of  some  change  in  the  environment.  The  change  in  the 
environment  may  be  initially  independent  of  the  action  of  the  organism,  but  at  some  point, 
the  reflexive  organism  responds  and  contributes  to  that  change.  The  direction  and  magnitude 
of  the  change  is  determined  by  the  evoked  reflex,  which  is  dependent  upon  the  internal  needs 
of  the  organism  and  the  external  circumstances.  Because  the  environment  generally  changes 
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slowly  relative  to  an  animate  organism,  much  of  the  new  information  will  be  due  to  changes 
induced  by  actions  of  the  agent. 

An  autonomous  system  must  independently  acquire  information  to  achieve  an  objective 
under  uncertainty.  For  example,  the  protozoan  is  uncertain  about  the  location  of  food  or  a  co¬ 
specific.  The  protozoan  reduces  uncertainty  by  its  mobility  through  the  environment,  for  the 
consequent  changes  increase  its  information.  To  use  information,  the  autonomous  agent  must 
have  sensors  for  its  need  (analogous  to  the  motive  force  for  DNA),  sensors  for  its 
environment  (analogous  to  the  selective  sensitivities  of  DNA),  and  a  means  to  encounter  and 
acquire  the  needed  information  (the  mobility  of  proteins  produced  by  DNA).  As  we  have 
tacitly  assumed  that  an  agent  has  coherent  boundaries,  these  three  other  requirements 
constitute  the  basis  for  autonomous  behavior. 

An  autonomous  robot  will  also  encounter  uncertainty.  This  uncertainty  should  be 
anticipated  by  mission  planners  because  of  the  many  possibilities  for  surprise  in  the  task 
environments,  including  an  element  of  randomness  inherent  in  the  robot's  control  processes 
and  dynamics.  Additionally,  in  a  working  system,  the  operation  of  the  robot  will  continually 
modify  the  appearance  of  the  environment,  either  by  disturbing  the  lay  of  the  objects  or  by 
changing  the  robot's  viewpoint.  The  autonomous  robot,  by  predicting  these  changes,  should 
be  able  to  control  the  increase  in  entropy  due  to  its  own  activity  and  avoid  disorientation.  An 
automatic  robot  would  not  be  so  prepared. 

4.3.5.7.3  Adaptation  Mechanisms:  Assimilation  and  Accommodation 

Autonomous  behavior  involves  three  components:  (1)  self-generation  of  activity,  (2)  self¬ 
suppression  of  activity,  and  (3)  self-testing  of  results.  The  organism  must  have  control  over 
its  own  on-off  switch,  that  is,  modulate  its  own  level  of  activation,  and  it  must  determine 
when  its  actions  have  achieved  its  goals.  As  the  environment  changes,  presenting  new 
information  to  the  organism,  it  must  alter  its  response  to  survive.  The  act  of  response 
modulation  is  called  adaptation. 

Animals  have  two  mechanisms  of  adaptation.  The  first  is  accommodation,  which  involves 
adjustments  of  the  internal  environment.  The  second  is  assimilation,  which  involves  motoric 
actions  on  the  external  environment.  The  regulation  of  blood  glucose  is  an  example  of 
accommodation,  while  eating  is  an  example  of  assimilation.  The  objective  of  adaptation  is 
survival,  but  more  specifically,  the  maintenance  of  the  optimal  state  for  survival,  which  we 
call  homeostasis.  Assimilation  mechanisms  are  usually  brought  to  play  when  accommodation 
mechanisms  have  reached  their  homeostatic  limits.  This  definition  of  adaptation  follows  from 
observations  that  agents  must  be  able  to  adjust  internal  conditions  and  operate  on  the 
environment  to  survive.  Each  mechanism  involves  the  play  of  automatic  processes. 
Accommodation  uses  reflexive  modulation  of  automatic  processes  to  adjust  the  internal 
environment,  while  assimilation  uses  the  reflexive  modulation  of  automatic  processes  to 
make  adjustments  to  the  external  environment. 

4.3.5.7.4  Providing  for  Robot  Autonomy 

The  biological  mechanisms  represent  real  working  examples  of  autonomous  systems,  the 
behavioral  capabilities  of  which  we  would  like  to  achieve  in  an  unmanned  system.  We  may 
avoid  the  pitfalls  inherent  in  the  application  of  models  of  cognition  that  are  characteristic  of 
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most  contemporary  robotics  control  algorithms  by  adhering  closely  to  the  biological 
mechanisms. 

We  attempt  to  emulate  the  biological  mechanisms  of  autonomy  because  something  is 
known  on  how  they  work.  We  can  borrow  from  this  literature.  The  autonomous  machines  are 
intended  to  assume  many  tasks  currently  performed  by  man,  in  man’s  work  space,  and  using 
man’s  tools  and  symbols.  A  machine  that  is  anthropomorphic  in  hardware  and  software  may 
most  easily  be  inserted  into  those  tasks. 

While  the  initial  implementation  of  analogous  mechanisms  may  not  produce  the  most 
impressive  behaviors,  we  assert  that  they  will  be  required  for  the  development  of  more  robust 
and  adaptive  behaviors. 

Generally,  traditional  AI  approaches  to  unmanned  systems  capitalize  on  constraints  in  the 
operational  environment,  e.g.,  an  un-patterned  floor  with  downward  looking  cameras — 
looking  for  the  appearance  of  the  line  demarking  the  boundary  between  wall  and  floor. 

Nature  also  takes  advantage  of  such  constraints.  The  common  housefly  observes  the  open  sky 
with  eyes  located  on  top  of  its  head  for  small,  dark,  moving  targets.  Houseflies  are  quite 
successful,  but  are  easily  confused  in  visually  complex  environments,  and  are  not  very  useful 
to  man.  However,  there  are  rather  mundane  tasks,  such  as  foraging,  that  can  be  performed  by 
simple  biological  systems  such  as  the  garden  slug,  that  might  also  be  efficiently  and  usefully 
accomplished  by  robots  using  similar  mechanisms. 

The  perceptual  capabilities  of  a  garden  slug  are  proportional  to  its  judgment  capabilities 
and  to  its  behavioral  capabilities.  This  general  law  of  functional  proportionality  is  sustained 
at  all  levels  of  the  phylogenetic  scale,  including  man.  A  necessary  conclusion  from  this  law  is 
that  the  perceptual  capabilities  of  man  are  going  to  be  reproduced  in  an  artificial  visual 
system  only  after  provisions  have  been  made  as  well  for  the  judgment  and  behavioral 
capabilities. 

To  achieve  autonomy  in  a  robot,  the  robot's  design  must  ensure  that  the  top  behavioral 
priority  for  the  robot  is  to  survive.  We  should  be  able  to  structure  the  task  situation  so  that  the 
robot  works  to  survive  and  views  our  own  survival  as  critical  to  its  own  (like  a  loyal  dog).  In 
this  way,  the  robot  will  be  autonomous  and  useful. 

At  this  point,  we  may  ask  what  are  the  necessary  reflexes  that  promote  survival  in  a  robot? 
Surely  they  will  be  similar  to  our  own.  The  robot  needs  to  preserve  its  physical  integrity,  it 
needs  to  maintain  an  adequate  energy  reserve,  it  needs  to  maintain  a  stable  and  consistent 
orientation  to  the  environment  and  to  maintain  freedom  of  movement.  Involved  in  these 
protections  are  reflexes  for  obstacle  avoidance,  avoidance  of  extremes  in  temperature, 
pressure,  vibration,  chemicals  and  other  irritants;  reflexes  to  orient  to  specific  sources  of 
energy  and  reflexes  to  consume  them;  and  reflexes  to  orient  to  gravity  or  the  skyline  or  some 
other  fixed  feature  of  the  operational  environment.  Recall  that  these  reflexes  will  control 
behavior  in  proportion  to  their  degree  of  importance  in  maintaining  survival  at  the  moment. 
For  example,  orientation  to  the  environment  should  take  precedence  over  the  consumption  of 
an  energy  source,  yet  when  energy  reserves  are  low,  consumption  should  proceed  even  under 
exposure  to  noxious  chemicals,  pressure,  or  temperature,  but  still  should  be  interrupted  by  an 
impending  collision  with  a  massive  object.  With  these  reflexes  alone,  a  robot  could  be 
expected  to  survive  in  a  temperate  climate.  It  might  even  perform  some  well-defined  task 
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with  great  reliability  if  the  task  was  tied  to  its  reflex  processes.  We  may  be  disappointed, 
however,  if  the  task  would  unexpectedly  change  in  some  way,  for  we  could  not  easily  adapt 
the  robot  to  different  environments. 

The  way  nature  has  handled  this  problem  is  to  permit  insignificant  environmental  events 
(those  that  have  initially  little  survival  relevance)  to  become  associated  with  those 
environmental  events  that  have  great  survival  relevance.  For  example,  if  a  robot  finds  an 
energy  source  consistently  in  a  certain  place,  then  returning  to  that  place  would  increase  the 
probability  of  again  encountering  the  energy  source,  even  if  none  was  currently  present. 
Returning  later,  or  just  waiting  around  may  pay  off  if  the  energy  source  is  intermittently 
present.  To  accomplish  this,  the  robot  needs  to  be  able  to  recognize  some  feature  of  the 
environment  in  addition  to  the  energy  source  and  be  able  to  attach  some  special  significance 
to  that  new  feature.  A  simple  mechanism  is  to  have  the  new  feature 

trigger  the  same  orienting  and  approach  reflex  as  the  energy  source  that  was  found  in  its 
vicinity.  The  biological  mechanism  for  this  process  is  known  as  classical  conditioning.  It  has 
been  well-described  in  the  biological  literature  and  can  be  implemented  in  hardware  and/or 
software,  as  many  have  shown.  We  have  noted  that  learning,  of  which  classical  and 
instrumental  conditioning  are  variants,  depends  upon  the  presence  of  an  association  ganglion 
or  brain.  There  is  a  huge  literature  on  the  architecture  of  brains  and  the  processes  that 
contribute  to  the  various  types  of  learning  that  can  be  used  by  the  robot  developer  to 
accomplish  analogous  processes  for  his  or  her  robots. 

Once  the  new  features  have  assumed  through  learning  some  survival  importance  for  the 
robot,  they  too  can  be  used  to  condition  additional  features  that  increase  the  robot's 
probability  of  staying  intact,  or  remaining  energized,  when  the  environment  becomes  less 
certain.  One's  entire  human  endeavor  can  be  connected  to  a  few  remote,  but  compelling 
reflexes,  some  of  which  may  be  unfulfilled  even  from  early  childhood.  But,  at  least  in  our 
robots,  if  we  educate  them  correctly,  we  may  not  need  to  hear  such  complaints. 
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5.  Summary  of  the  Top  10  Issues 


This  section  summarizes  10  issues  that  emerged  from  the  compilation  of  the  many  lessons 
learned  above.  We  provide  three  issues  in  the  area  of  Operations,  three  in  the  area  of 
Programmatics,  and  four  in  the  area  of  Technologies. 

The  reader  may  rightly  wonder  how  we  derived  and  selected  the  top  10  issues  from  the 
many  Lessons  Learned  presented  in  this  compilation.  Since  we  depended  upon  the  sampled 
community  of  experts  for  our  basic  input,  we  could  have  used  a  voting  method  and  identified 
the  top  lessons  based  upon  the  largest  number  of  occurrences.  Surely,  the  frequency  of 
occurrence  might  indicate  that  the  problems  that  generated  the  particular  lesson  came  up 
again  and  again.  It  also  might  indicate  that  the  frequently  cited  lesson  was  a  hard  one  to  learn. 
We  trust,  however,  in  the  superior  experience  of  our  sample,  and  therefore  attribute  the 
frequency  of  the  lesson  to  the  commonality  of  an  underlying  problem.  Where  possible,  we 
determined  the  causes  of  those  problems  and  developed  them  as  issues. 

However,  not  all  of  the  Lessons  Learned  were  clearly  associated  by  their  authors,  through 
the  problem  definition,  with  a  fundamental  cause.  This  uncertainty  created  an  opportunity  for 
us  to  look  independently  into  the  situation,  and  suggest  causes  or  errors,  either  in  concept  or 
in  approach,  that  might  account  for  some  of  the  more  intractable  problems.  We  were  thus 
able  to  derive  additional  issues  from  this  editorial  assessment.  We  believe  that  these  issues, 
while  associated  with  the  many  Lessons  Learned,  deserve  greater  attention  in  the  robotics 
community.  These  issues  probably  do  not  attract  universal  agreement,  rather  they  represent 
an  alternative  view  of  the  situation.  As  a  counterpoint,  our  issues  may  stimulate  dialogue 
essential  to  the  discovery  of  new  solutions  to  the  persistent  problems  that  are  evident  herein. 

If  the  reader  is  dissatisfied  with  our  listing  of  the  top  10  issues,  then  we  invite  the  reader  to 
return  to  the  many  other  Lessons  Learned  presented  herein  for  more  relevant  choices.  We 
acknowledge  that  the  most  important  lessons  to  be  learned  for  any  one  reader  would  be  those 
lessons  that  contribute  most  to  the  success  of  his  or  her  project.  Finally,  we  admit  that  there 
are  probably  many  valuable  Lessons  Learned  that  did  not  make  it  into  our  compilation.  We 
can  only  apologize  for  our  omissions,  and  advise  the  reader  to  be  on  the  lookout  for  these 
unrecorded  lessons. 

5.1  OPERATIONS 

5.1 .1  Uncertainty  Promotes  Survival 

There  are  many  corollaries  of  this  truism.  The  most  recent,  from  the  Army's  Future 
Combat  Systems  concept,  is  that  mobility  and  maneuverability  are  essential  tactical 
capabilities.  The  fundamental  advantage  of  mobility  and  maneuverability  is  in  the 
consequential  reduction  in  predictability  that  it  affords,  for  an  adversary  that  is  uncertain  of 
our  next  move  cannot  prepare  an  appropriate  countermove.  A  second  corollary  is  that 
automatic  processes  do  not  promote  survival.  Automatic  processes  are  very  deterministic, 
and  fail  to  adapt  to  the  challenges  of  complex  environments. 

Uncertainty  also  promotes  perception.  An  indeterministic  controller  (based  on  fuzzy  logic 
and  bi-directional  mapping)  is  uncertain  to  itself  as  well  as  to  observers,  permitting  the 
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construction  of  internal  hypotheses  or  expectations.  These  hypotheses  drive  behavior.  Self¬ 
certainty  is  improved,  without  sacrifice  to  survivability,  through  the  processes  of  prediction 
precedent  to — and  validation  consequent  to  self-generated  behavior. 

Whether  robots  are  used  in  logistical  support,  in  RSTA  support,  or  in  tactical  force 
projection,  they  must  be  survivable,  and  to  survive,  they  must  demonstrate  and  deal  with 
uncertainty. 

Operators,  however,  prefer  to  be  able  to  accurately  predict  and  control  the  behavior  of 
their  robots.  While  this  provides  advantages  for  safe — if  limited — operation  among  friendly 
forces,  predictability  has  definite  disadvantages  for  operation  in  unpredictable  environments. 
This  disadvantage  is  due  to  the  inherent  cognitive  and  perceptual  limitations  of  a 
deterministic  system  and  to  the  opportunistic  activities  of  hostile  forces.  Predictable  behavior 
is  thus  not  conducive  to  survival.  A  degree  of  uncertainty  must  be  inherent  in  robot 
controllers  for  those  robots  to  be  successfully  used  in  real-world  environments,  including 
tactical  operations. 

5.1 .2  Many  Simple  Cooperating  Agents  are  Superior  to  One  Complex  Agent 

The  superiority  of  large  numbers  has  always  been  valid  in  military  affairs.  It  is  based  on 
inviolable  physical  principles.  It  applies  to  natural  organisms,  and  will  apply  to  robotics  as 
well.  The  downside  to  the  use  of  large  numbers  of  robots  in  the  military  context  is  in  the 
difficulty  of  control.  Operators  will  be  wary  of  such  agents  when  control  is  a  question.  New 
operational  doctrine  will  likely  be  required  to  accommodate  many  robot  agents  in  a  tactical 
environment. 

A  single  complex  agent  is  limited  in  time  and  space.  It  is  appropriately  tasked  only  to  a 
single — if  complex — mission.  It  cannot  be  sacrificed  without  great  cost.  But,  it  is  inherently  a 
technological  Goliath  that  can  be  disabled  through  any  number  of  system  vulnerabilities.  On 
the  other  hand,  in  artificial  systems,  unit  reliability  and  cost  are  inverse  functions  of 
complexity.  Multiple  agents  permit  parallel  distribution,  and  afford  great  flexibility  in 
deployment.  Simple  agents  are  easier  to  design,  produce,  use,  and  maintain. 

The  problem  is  that  effective  processes  that  promote  cooperation  among  many  simple 
agents  engaged  in  tasks  relevant  to  MCM  operations  have  yet  to  emerge  from  robotics 
research,  even  though  there  has  been  considerable  attention  in  the  robotics  community 
focussed  on  this  problem.  During  the  development  of  the  VSW  UUV  MCM  concept  of 
operations,  R&D  funds  should  be  allocated  to  explore  the  possibilities  for  cooperative 
behaviors  in  the  VSW  environment.  There  is  thus  a  high  program  risk  to  the  early 
dependence  upon  multi-agent  coordination  for  prosecution  of  the  VSW  MCM  task. 

5.1.3  New  Technology  Forces  Changes  in  Operations 

The  military  community  tends  to  view  technology  as  an  enabler  of  operations,  but  history 
has  demonstrated  repeatedly  that  new  technology  is  a  transformer  of  military  operations.  As 
every  new  introduction  of  technology  into  the  military  context  forces  changes  in  operations, 
it  is  preferred  to  force  those  changes  upon  our  adversaries,  and  be  the  first  ones  to  adapt  to 
them.  Thus,  the  MCM  program  office  must  remain  alert  to  the  opportunities  for  change  in 
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operations  that  would  be  permitted  and  required  by  the  introductions  of  different  robotic 
technologies. 

History  has  also  shown  that  technologies  are  extremely  difficult  to  control.  Nearly  every 
technology  that  could  be  applied  to  improve  the  unmanned  detection,  classification,  and 
neutralization  of  mines  in  shallow  water,  very  shallow  water,  and  SZ,  could  as  easily  be 
applied  to  improve  the  effectiveness  of  mines  themselves  in  the  objective  to  detect,  classify, 
and  attack  targets,  and  to  avoid  detection  and  neutralization  in  turn  during  MCM  operations. 
The  MCM  program  office  must  also  consider  the  potential  evolutionary  paths  of  mine  and 
MCM  technologies  and  operations  as  it  pursues  its  solutions. 

5.2  PROGRAMMATICS 

5.2.1  Understanding  between  the  User  and  the  Developer  is  Critical 

Successful  programmatic  decisions  cannot  be  made  without  the  program  office/developer 
and  the  user  acquiring  a  comprehensive  understanding  of  each  other's  constraints, 
capabilities,  and  expectations.  The  user  has  come  to  the  program  office  with  a  problem 
because  his  old  methods  of  operation,  supported  by  old  technology  solutions,  no  longer  work. 
The  user  is  trained  in  the  old  methods,  and  user  experience  shapes  one’s  perception  of  what  is 
possible.  To  accomplish  a  new  solution,  the  developer  must  understand  the  application,  and 
the  user  must  understand  the  proposed  solution,  and  adjust  methods  of  operation  accordingly. 
The  primary  risk  of  misunderstanding  is  a  product  that  is  at  best  useless. 

5.2.2  Understanding  the  Technology  is  Cost-Effective 

Successful  programmatic  decisions  cannot  be  made  without  a  comprehensive 
understanding  of  the  supporting  technologies.  The  MCM  program  office  must  maintain  a 
continuous  survey  of  the  emerging  technological  capabilities  in  all  areas  of  relevance  to  the 
MCM  problem.  This  knowledge  will  facilitate  long-range  planning  and  avoid  dead-end 
products. 

5.2.3  Simpler  Solutions  Provide  Better  Foundations 

A  simple  solution,  however,  does  not  mean  a  solution  that  has  already  been  demonstrated. 
Our  definition  of  a  simple  solution  is  that  process  that  meets  a  few  of  the  requirements 
without  sacrificing  or  violating  any  of  the  other  requirements  applicable  to  the  system  of 
which  the  subject  solution  is  a  component.  By  contrast,  a  complicated  solution  is  that 
process  that  meets  some  of  the  requirements,  while  integrating  badly  with  more  traditional 
solutions  to  the  remaining  requirements.  To  the  degree  that  requirements  are  independent, 
several  simple  solutions  may  be  found  to  the  set  of  requirements.  One  or  more  simple 
solutions  may  be  viable,  even  though  not  all  of  the  requirements  may  have  been  satisfied  in 
the  subject  solutions. 

To  deal  with  the  remaining  requirements,  the  MCM  program  office  should  look  to  those 
simple  solutions  that  have  the  highest  probability  of  extension,  that  is,  that  can  be  built  upon. 
Requirements  may  be  added  to  the  solution  only  as  long  as  the  principle  of  simplicity  is 
maintained.  Natural  selection  in  evolution  is  the  model  for  this  process. 
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5.3  TECHNOLOGIES 


5.3.1  Integration  Is  Not  Easy 

When  humans  address  a  problem,  they  use  tools,  some  ancient,  some  new,  that  experience 
has  proven  useful.  These  tools  may  include  new  transducers  of  environmental  emissions  such 
as  an  IR  camera,  as  well  as  force  multipliers  such  as  a  lever,  or  force  reducers  as  appropriate 
to  permit  us  to  manipulate  objects  at  different  scales.  The  integration  of  these  tools  with  our 
own  innate  capabilities  is  accomplished  anew  each  time  that  we  take  the  tool  in  hand. 
Learning,  or  long-term  adaptation,  does  play  a  role,  but  what  is  learned  is  the  refined  control 
of  the  innate  capability.  Each  new  tool  is  used  through  an  existing  skill  base. 

When  we  attempt  to  provide  similar  tools  to  a  robot,  we  face  two  difficulties:  (1)  the  robot 
has  little  if  any  innate  capability,  and  (2)  the  robot  has  no  capacity  to  adapt  to  the  new  tool. 
Thus,  the  robot  is  redesigned  with  each  addition  of  a  tool.  This  redesign  is  the  fundamental 
problem  of  integration.  The  difficulties  of  integration  would  be  minimized  if  the  robot 
employed  an  existing  interface  to  use  new  tools,  and  if  the  robot  could  cooperate  through 
adaptations  of  its  control  algorithms.  These  adaptations  are  a  proven  method  of  vertical 
(hierarchical)  integration. 

The  MCM  program  office  should  encourage  the  selection  or  development  of  core 
capabilities  in  a  robotic  agent.  These  core  capabilities  should  be  task  independent,  adaptive, 
and  therefore  of  general  utility.  The  core  capabilities  should  then  facilitate  the  incorporation 
of  unique  tools  designed  to  address  the  special  circumstances  of  the  MCM  tasks  and 
environment.  There  is  a  significant  program  cost  risk  in  pursuing  solutions  that  do  not 
integrate  vertically. 

5.3.2  Communications  Are  Not  Dependable 

Communications,  even  under  the  best  of  transmission  and  reception  circumstances,  can 
not  be  relied  upon  to  synchronize  information  and  understanding.  When  either  the 
transmission  or  reception  of  signals  fail,  even  poor  communication  is  impossible.  Humans  get 
by  with  very  low  bandwidth  communications  for  this  reason.  Similarly,  the  most  useful 
robots  will  demand  the  least  from  humans  during  task  performance.  Autonomy  will  be 
necessary  to  permit  the  low  levels  of  communications  that  will  be  available.  The  MCM 
program  office  should  explore  technology  and  operational  solutions  that  avoid  heavy 
communication  requirements.  There  is  a  significant  operational  risk  in  a  dependence  upon 
communications,  including  satellite  communications  that  serve  GPS. 

5.3.3  Automaticity  Is  Not  Autonomy 

Implementing  automatic  processes  on  a  robot  can  reduce  the  decision-making 
requirements  of  the  human  operator,  but  risk  functional  failure  when  the  control  algorithms 
that  govern  the  automatic  processes  have  not  been  designed  for  the  prevailing  conditions  that 
either  generate  or  require  a  response. 
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Figure  15.  WWI  observation  balloon. 

The  observation  balloon  is  an  example  of  an  automatic  process  (even  though  a  human 
observer  rode  along  as  a  passenger  in  the  suspended  basket)  as  it  used  passive  lift  in 
order  to  gain  altitude.  The  observer  had  little  control  over  the  flight  trajectory  of  the 
balloon,  and  as  a  consequence,  usually  tethered  it  to  a  point  on  the  ground. 

Autonomy  is  not  a  mysterious  life  force  that  will  spontaneously  arise  in  our  robots  when 
we  provide  them  with  sufficient  sensors  and  computational  resources.  Autonomy  results  from 
the  self-modulation  of  responses  that  impact  conditions  in  the  internal  and  external 
environments,  based  upon  the  confluence  of  factors  prevailing  in  both,  following  rules  that 
promote  the  integrity  and  well-being  of  the  agent.  Thus,  the  basis  for  robot  autonomy  could 
be  satisfied  with  the  provision  of  very  few  processes.  The  criterion  for  successful  autonomy 
is  survival.  If  survival  is  not  a  required  mission  or  task  objective  of  the  robot,  then  its 
processes,  while  automatic,  will  not  be  autonomous,  and  the  robot  will  likely  fail  as  soon  as 
the  operating  conditions  deviate  from  the  designed  range  of  its  automatic  mechanisms,  or 
whenever  they  become  irrelevant  to  the  integrity  of  the  robot.  The  MCM  program  office 
should  encourage  the  development  of  fundamental  autonomous  capabilities  in  the  first  and 
lowest  level  of  technological  solutions.  This  development  will  establish  the  necessary  basis 
for  the  evolution  of  systems  capable  of  dealing  adaptively  and  appropriately  with  more 
complex  and  unpredictable  environments. 
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Figure  16.  WWI  biplane. 

The  biplane,  due  to  its  use  of  active  lift,  exemplifies  an  autonomous  process  and  the 
difference  between  automaticity  and  autonomy.  Autonomy  optimizes  control,  and 
contributes  an  element  of  unpredictability  that  promotes  survival.  Observation 
balloons  were  frequent  targets  of  biplanes  during  the  First  World  War. 

5.3.4  The  Road  from  Teleoperation  to  Autonomy  Does  Not  Exist 


Figure  17.  WWI  dirigible. 

Even  though  the  balloons  of  the  first  World  War  were  developed  into  rigid  motorized 
airships,  armed  with  machine  guns  and  bombs,  they  still  depended  upon  passive  lift 
and  were  limited  in  control  and  maneuverability.  For  the  objectives  of  aviation, 
passive  lift  did  not  take  us  to  the  modern  airplane. 

The  road  from  teleoperation  to  automaticity  probably  does  exist,  but  automaticity  is  not 
autonomy,  as  a  balloon  is  not  an  airplane.  The  mechanisms  of  autonomy  are  fundamental  and 
are  re-expressed  at  all  higher  levels  of  the  control  architecture  of  an  autonomous  system. 
They  are  bypassed  only  in  pathology  and  disease. 

The  adherence  to  human  control  over  robot  operation  could  impede  progress  toward 
achieving  robot  autonomy.  If  humans  remain  in  the  UGV  control  loop,  then  inadequacies  in 
our  robot  control  algorithms  will  be  masked,  and  we  will  not  be  developing  the  necessary 
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autonomous  foundations  for  the  higher-level  perceptual  and  cognitive  processes  that  we 
desire  in  machine  intelligence. 

We  should  not  attempt  to  follow  a  roadmap  from  teleoperation  through  semiautonomous 
to  autonomous  capabilities,  for  that  road  does  not  exist  in  reality.  Rather  we  should  develop 
capabilities  of  fully  autonomous,  though  behaviorally  simple,  robots  from  the  onset, 
following  the  principles  of  autonomy  outlined  herein.  But  to  do  this,  we  must  start  with  the 
simplest  of  tasks  and  add  task  and  behavioral  complexity  only  to  the  degree  that  autonomy  is 
not  compromised. 


Figure  18.  A  swarm  of  biplanes  bringing  down  a  dirigible. 

The  dirigibles  were  large  and  heavily  armed,  but  their  low  airspeeds  and  lack  of 
maneuverability  made  them  vulnerable  to  the  coordinated  attacks  of  the  more  agile 
biplanes  that  took  advantage  of  active  lift. 

5.4  CONCLUDING  CHALLENGE 

The  problem  with  starting  with  simple  autonomous  agents  is  twofold.  First,  simple 
autonomous  robotic  systems  that  are  also  useful  are  difficult  to  define.  Second,  only  with  a 
clear  promise  of  utility  will  operators  be  interested  in  adopting  the  new  robotics  products. 
The  robotics  development  community  needs  to  maintain  the  operator/  customer's  interest  in 
order  to  receive  the  necessary  resources  for  development.  The  challenge  then  is  to  discover 
new  ways  to  use  simple  self-interested  (autonomous)  robotic  systems. 
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APPENDIX  A 


RELEVANT  DOD  R&D  PROGRAMS 

Listed  here  are  a  sample  (not  exhaustive)  of  DoD  R&D  Programs  that  have  potential  to 
contribute  capabilities  to  the  VSW  MCM  UUV  Program. 

DARPA 

Acoustic  Microsensors,  MTO/ATO,  PM:  Dr.  Edgar  J.  Martinez 

Adaptive  Computing  Systems  (ACS),  TTO,  PM:  Dr.  William  Phillips 

Autonomous  Negotiating  Teams  (ANT),  ITO,  PM:  Dr.  Janos  Sztipanovits 

Buoyant  Cable  Array  Antenna  (BCAA),  ATO,  PM:  CAPT  John  Kamp 

Controlled  Biological  and  Biomimetic  Systems,  DSO,  PM:  Dr.  Alan  Rudolph, 
http  ://www.  darpa.  mil/dso/thrust/sp/Cbs/Pro  grams  .html 

Distributed  Robotics,  MTO,  PM:  Dr.  Elana  Ethridge 

Dog's  Nose,  ATO,  PM:  Dr.  Thomas  Altschuler, 
http://www.darpa.mil/ato/programs/UXO/index.html 

Drag  Reduction  Program,  ATO,  PM:  Dr.  Parney  Albright 

Future  Combat  Systems  (FCS),  TTO,  PM:  http://www.darpa.mil/tto/fcs/index.html 

Micro-Electromechanical  Sensor  (MEMS)  Inertial  Navigation  System  (INS),  SPO,  PM:  Lt 
Col  Gregory  Vansuch 

Mobile  Autonomous  Robot  S/W,  ITO,  PM:  Dr.  Douglas  Gage 

Networked  Embedded  Software  Technology  (NEST),  ITO,  PM:  Janos  Sztipanovits, 
http://www.darpa.mil/ito/Solicitations.html 

Robonaut  (ARMS),  ITO/NASA  JSC,  PM: 
http://www.isc.nasa.gov/er  er/html/robonaut/robonaut.html 

Software  for  Distributed  Robotics  (SDR),  ITO,  PM:  Dr.  Douglas  Gage 

Tactical  Mobile  Robots  (TMR),  ATO,  PM:  Douglas  Dyer  (May  2001),  small  man-portable 
robots 
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ONR 


Gladiator  Tactical  Unmanned  Ground  Vehicle  Program.  Jeff  Bradel,  ONR  353,  UGV 
Deputy  Program  Manager. 

Mathematical,  Computer,  and  Information  Sciences  Division 

Autonomous  Systems,  PM:  Dr.  Behzad  Kamgar-Parsi  (via  ONR  web  site) 

Autonomous  Systems,  PM:  Mr.  James  Valentine,  (703)  588-0074  (via  Mr.  Jack 
Taylor) 

Surveillance,  Communications,  and  Electronic  Combat  Division 

Target  Tracking  and  Sensor  Fusion,  PM:  Dr.  Rabinder  N.  Madan 

Ocean,  Atmosphere,  and  Space  Science  and  Technology  Department 
Organic  MCM  FNC,  PM:  Dr.  Doug  Todoroff 
Shoaling  Waves  DRI, 

Diver  and  UUV  System  and  Technologies  for  VSW/SZ  MCM  Missions,  Brian 
Glance  ONR,  252  (703)  696-2596 

Naval  Expeditionary  Warfare 

Mine  Counter  Measures  (Code  32):  Organic  Mine  Hunting  and  Reconnaissance 
POC:  LTC  Mark  Miller 

OSD  Joint  Robotics  Program 

UGV-S  JPO,  PM:  LTC.  Richard  LeVan, 

■  Robotic  Combat  Support  System  (RCSS) 

■  Standardized  Robotic  System  (SRS) 

■  Man-Portable  Robotic  System  (MPRS) 

■  Tactical  Unmanned  Vehicle  (TUV) 

■  Viking 

PMS-EOD 

■  Basic  Unexploded  Ordnance  Gathering  System  (BUGS) 

■  Remote  Ordnance  Neutralization  System  (RONS) 

Air  Force  Research  Laboratory,  PM:  A1  Nease 

■  Robotic  Ordnance  Clearing  System  (ROCS) 

■  All-purpose  Remote  Transport  System  (ARTS) 

■  Advanced  Force  Protection  Robotic  System 

■  Next  Generation  Field  Robotic  System 

Physical  Security  Equipment,  PM:  LTC  Michael  Bonheim 
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Mobile  Detection  Assessment  and  Response  System  -  Interior  (MDARS-I) 
Mobile  Detection  Assessment  and  Response  System  -  Exterior  (MDARS-E) 


Army  Research  Laboratory,  PM:  Chuck  Shoemaker 

.  UGVTEE 
.  DEMO  III,  XUV 

Aviation  and  Missile  Command  Research,  Development  and  Engineering  Center 

■  Joint 

Architecture  for  Unmanned  Ground  Systems  JAUGS 

NSF  National 

Science  Foundation 

Robotics  and  Human  Augmentation,  CISE,  IIS.  PM:  Vladimir  Lumelsky,  (703)  292-8980. 
AFOSR  Air  Force  Office  of  Scientific  Research,  http://www.afosr.af.mil/ 
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APPENDIX  B 


ACRONYMS 


AGC 

automatic  gain  control 

ATD 

advanced  technology  demonstration 

ATR 

automatic  target  recognition 

AUSS 

autonomous  underwater  search  system 

AUV 

autonomous  underwater  vehicle 

BAA 

broad  agency  announcement 

BIPS 

billion  instructions  per  second 

BIT 

built-in  test 

C2 

command  and  control 

CONOPS 

concept  of  operations 

COTS 

commercial  off-the-shelf 

DARPA 

Defense  Advanced  Projects  Agency 

DGPS 

differential  GPS 

DNA 

deoxyribonucleic  acid 

DoD 

Department  of  Defense 

DUSD(S&T) 

Deputy  Under-Secretary  of  Defense  for  Science  and  Technology 

EMI 

electromagnetic  interference 

EMD 

engineering  and  manufacturing  development 

EOD 

explosive  ordnance  disposal 

FCS 

Future  Combat  System  (Army  program) 

FIDO 

field  integrated  design  and  operations 

FLIR 

forward-looking  infrared 
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GPS 

global  positioning  system 

HMMWV 

highly  mobile  multipurpose  wheeled  vehicle 

ICD 

interface  control  document 

INS 

inertial  navigation  system 

IPT 

integrated  product  team 

IR 

infrared 

JAMC 

joint  amphibious  mine  countermeasures 

JAUGS 

joint  architecture  for  unmanned  ground  systems 

LAN 

local  area  network 

LMRS 

Long-Term  Mine  Reconnaissance  System 

LOS 

line  of  sight 

MARS 

Mobile  Autonomous  Robot  Software  (DARPA  program) 

M&S 

modeling  and  simulation 

MCM 

mine  counter  measures 

MDARS 

Mobile  Detection,  Assessment,  and  Response  System;  I  -  interior,  E  - 
exterior 

MOE 

measures  of  effectiveness 

MOP 

measures  of  performance 

MPRS 

man  portable  robotic  system 

MS 

milestone 

NAS 

National  Academy  of  Sciences 

NIST 

National  Institute  of  Standards  and  Technology 

NTDR 

near-term  digital  radio 

OCU 

operational  control  unit 

ONI 

Office  of  Naval  Intelligence 
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ONR 

Office  of  Naval  Research 

ORD 

operational  requirements  document 

PM 

program  manager 

PPI 

planned  product  improvement 

R&D 

research  and  development 

REMUS 

Remote  Environmental  Monitoring  Unit-S 

RF 

radio  frequency 

RONS 

Remote  Ordnance  Neutralization  System 

ROV 

remotely  operated  vehicle 

RSTA 

reconnaissance,  surveillance,  and  target  acquisition 

SCOWRScalable  Coordination  of  Wireless  Robots 

SDR 

software  for  distributed  robotics  (DARPA  program) 

SPAWAR 

Space  and  Naval  Warfare  Systems  Command 

SSC  San  Diego 

SPAWAR  Systems  Center,  San  Diego 

STO 

science  and  technology  objectives 

SZ 

surf-zone 

TIPS 

trillion  instructions  per  second 

TMR 

Tactical  Mobile  Robots  (DARPA  program) 

TOV 

teleoperated  vehicle 

UAV 

unmanned  air  vehicle 

UGV 

unmanned  ground  vehicle 

uuv 

unmanned  underwater  vehicle 

uxo 

unexploded  ordnance 

vsw 

very  shallow  water 
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WHOI  Woods  Hole  Oceanographic  Institute 

XUV  experimental  unmanned  vehicle  (Demo  III) 
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APPENDIX  C 


GLOSSARY 

Agent  An  entity  engaged  in  an  assigned  task. 

Automaticity  The  state  of  a  system  when  it  is  governed  entirely  by  automatic 

processes 

Autonomy  The  state  of  a  system  when  it's  automatic  processes  are  modulated  by 

the  confluence  of  both  internal  and  external  conditions 

Baud  Unit  of  signaling  speed  equal  to  one  code  element  per  second 

Cyborg  The  product  of  the  integration  of  artificial  components  with  a  natural 

organism.  [SAIC,  1997] 

Endogenous  Produced  or  generated  within  the  agent 

Exogenous  Provided  to  the  agent  from  an  external  source 

Learning  Long-term  changes  in  response  probabilities. 
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